GitLab

添加 /antigravity/v1/* 和 /antigravity/v1beta/* 路由：
- 通过 ForcePlatform 中间件强制使用 antigravity 平台
- 跳过混合调度逻辑，仅调度 antigravity 账户
- 支持按分组优先查找，找不到时回退查询全部 antigravity 账户

修复 context key 类型不匹配问题：
- middleware 和 service 统一使用字符串常量 "ctx_force_platform"
- 解决 Go context.Value() 类型+值匹配导致的读取失败

其他改动：
- 嵌入式前端中间件白名单添加 /antigravity/ 路径
- e2e 测试 Gemini 端点 URL 添加 endpointPrefix 支持

- 后端：账户模型添加 IsMixedSchedulingEnabled() 方法，读取 extra.mixed_scheduling
- 后端：gateway_service 和 gemini_messages_compat_service 支持混合调度逻辑
- 后端：分组创建支持指定 platform 参数
- 前端：账户创建/编辑弹窗添加混合调度开关（仅 antigravity 账户显示）
- 前端：混合调度开关添加问号图标和 tooltip 说明
- 前端：GroupSelector 支持根据 mixedScheduling 属性过滤分组
- 前端：分组创建支持选择 platform
- 测试：e2e 测试添加 ENDPOINT_PREFIX 环境变量支持混合/隔离模式测试
- 测试：删除过时的 Claude signature 测试用例

- 新增 TestClaudeMessagesWithClaudeSignature 测试
- 验证历史 thinking block 带有 Claude signature 时的处理
- 修复配额刷新服务的次要问题

后端:
- 新增 AntigravityQuotaRefresher 定时刷新配额
- Client 添加 FetchAvailableModels 方法获取模型配额
- 配额数据存入 account.extra.quota 字段

前端:
- AccountUsageCell 支持显示 Antigravity 账户配额
- UsageProgressBar 新增 amber 颜色
- 显示 G3P/G3F/G3I/C4.5 四个配额进度条

- 添加 //go:build e2e tag，CI 不会自动运行这些测试
- Makefile 添加 test-e2e 目标用于本地手动运行

Antigravity 不支持 count_tokens 转发，直接返回估算值，
与 Antigravity-Manager 和 proxycast 实现保持一致。

修复 count_tokens 请求选择到 Antigravity 账户时导致 401 的问题。

将测试从无效signature改为无signature场景：
- 无效 signature 应该被上游拒绝（预期行为）
- Gemini 模型接受没有 signature 的 thinking block

参考 Antigravity-Manager 的实现：
- 添加 allowDummyThought 参数，只有 gemini-* 模型才启用
- Claude 模型通过 Vertex API 需要有效的 thought signatures
- thinking block 保留原有 signature
- tool_use 只在 Gemini 模型时才使用 dummy signature

- function_call 无条件添加 dummy thought_signature（与 proxycast 一致）
- thinking block 在 thinking 模式下统一使用 dummy signature 替换历史无效 signature
- 添加测试用例：TestClaudeMessagesWithInvalidThinkingSignature

- 添加 dummyThoughtSignature 常量，在 thinking 模式下为无 signature 的 tool_use 自动添加
- 增强 cleanJSONSchema：过滤 required 中不存在的属性，确保 type/properties 字段存在
- 扩展 excludedSchemaKeys：增加 $id, $ref, strict, const, examples 等不支持的字段
- 修复 429 重试逻辑：仅在所有重试失败后才标记账户为 rate_limited
- 添加 e2e 集成测试：TestClaudeMessagesWithThinkingAndTools

- 移除未使用的 hasExpandableActions 计算属性
- 移除未使用的 toggleActionsExpanded 函数
- 修复 TypeScript 类型检查错误

- 移除操作列表头的展开/折叠按钮和图标
- 该功能已被操作列内的'更多'按钮替代
- 保留底层的展开/收起逻辑供'更多'按钮使用

- 修复RedeemView订阅刷新失败导致流程中断的问题
  将订阅刷新隔离到独立try/catch，失败时仅显示警告
- 修复DataTable resize事件监听器泄漏问题
  确保添加和移除使用同一个回调引用
- 修复订阅状态缓存导致强制刷新失效的问题
  force=true时绕过activePromise缓存，clear()清空缓存
- 修复图表主题切换后颜色不更新的问题
  添加图表ref并在主题切换时调用update()方法

- 在 Dashboard 页面加载时强制刷新订阅状态
- 在兑换订阅卡密后立即刷新订阅状态
- 清理订阅轮询相关注释

- DataTable组件操作列自适应
- 优化各种Modal弹窗
- 统一API调用方式（AbortSignal）
- 添加全局订阅状态管理
- 优化各管理视图的交互和布局
- 修复国际化翻译问题

  - apiKeyService.GetByKey(...) 返回的“找不到 API key”在这个项目里通常会被翻译成业务错误（比如
    service.ErrApiKeyNotFound 这类 ApplicationError），而不是直接把 gorm.ErrRecordNotFound 透传到中
    间件层。
  - 因此你在中间件里用 errors.Is(err, gorm.ErrRecordNotFound) 去判断“无效 key”，很容易匹配不到（尤其
    是：后面加 Redis 缓存、换存储实现、或测试里用 stub repo 时，根本不会出现 gorm 的错误）。
  - 匹配不到时就会走到 500 Failed to validate API key，导致无效 API key 被错误地当成服务端故障返回
    500（应该是 401）。

  修复思路：中间件不要依赖 gorm 的错误，改成判断业务层错误，例如：

  if errors.Is(err, service.ErrApiKeyNotFound) {
      abortWithGoogleError(c, 401, "Invalid API key")
      return
  }

  如果你把 GetByKey 的“not found”统一封装成业务错误，这样才不会被底层实现（gorm/redis/mock）影响。

使用 `id -u` 替代 `$EUID` 进行 root 权限检查。
`$EUID` 是 bash 内置变量，在通过 pipe 执行脚本时可能不可靠。

问题：当分配订阅天数过大时，expires_at 年份可能超过 9999，
导致 time.Time JSON 序列化失败（RFC 3339 要求年份 <= 9999），
使后台无法显示和删除异常数据。

修复：
- handler 层添加 validity_days 最大值验证（max=36500，即100年）
- service 层添加 MaxValidityDays 和 MaxExpiresAt 双重保护
- 启动时自动修复已存在的异常数据（expires_at > 2099年）

Implement deferred batch update mechanism to reduce database load:

- Add DeferredService for batching account last_used_at updates
- Add TimingWheelService for efficient recurring task scheduling
- Integrate with GatewayService and OpenAIGatewayService
- Implement BatchUpdateLastUsed repository method using CASE...WHEN SQL
- Fix golangci-lint error: Replace interface{} with any

Benefits:
- Reduces database writes by batching updates (10-second intervals)
- Improves request throughput by deferring non-critical updates
- Maintains accurate account usage tracking for scheduling

问题：仪表盘“最近用量”调用 /usage 时传入完整 ISO 时间戳（含时分秒/时区），后端 start_date/end_date 仅接受 YYYY-MM-DD，导致请求参数校验失败，页面无法正常展示最近用量。

解决：
- loadRecentUsage 改为传入 YYYY-MM-DD（从 toISOString() 取日期部分），与后端参数格式约定保持一致
- 补充注释说明：后端会将 end_date 扩展到当日结束时间，以及 toISOString() 为 UTC 可能带来的统计口径差异
- 同步修正 usageAPI.getByDateRange 的参数注释，避免后续误用

验证：npm -C frontend run build

feat 增加 caddy 示例安全反向代理

# Conflicts: