降低 admin/dashboard 读路径压力，避免 snapshot-v2 并发击穿

[xvhuan]

背景

线上排查时，后台 admin/dashboard 这条链路里还有几块重查询会直接打到 usage_logs：trend、models、groups、api-keys-trend、users-trend，而 snapshot-v2 在缓存 miss 时会串行组装这些子块。高并发下如果多个相同请求同时 miss，就会把读压集中打到数据库，放大后台卡顿。

这次 PR 不改统计口径、不改表结构、不新增聚合表，只在 handler 层做短 TTL 缓存和并发合并，先把 admin/dashboard 的读放大问题收住。

改动内容

• 为以下接口增加 30 秒结果缓存，缓存 key 覆盖时间范围、粒度和过滤参数：
  • GET /api/v1/admin/dashboard/trend
  • GET /api/v1/admin/dashboard/models
  • GET /api/v1/admin/dashboard/groups
  • GET /api/v1/admin/dashboard/api-keys-trend
  • GET /api/v1/admin/dashboard/users-trend
• 给 snapshot-v2 缓存增加 singleflight 并发合并，避免相同 key 在缓存 miss 时并发击穿。
• snapshot-v2 的组装过程改为复用上述 section 级缓存 helper，而不是每次直接下钻到 service/repository。
• 保留现有 repository 查询逻辑和返回结构，不改变现有统计语义。
• 补充缓存命中和缓存 key 优先级相关测试。

为什么这样做

• 当前已有的 usage 聚合表只能低风险覆盖一部分 trend 场景，models、groups、users-trend 还没有现成的预聚合读模型。
• 如果这一步直接改 SQL 口径或新上聚合表，风险会明显更高，也更容易影响其他后台功能。
• 先把重查询统一放到 handler 层缓存，并在 snapshot-v2 上做并发合并，可以在不改变业务语义的前提下，先降低数据库读压。

风险控制

• 不改数据库表结构。
• 不改 repository 的聚合 SQL 口径。
• 不改接口协议和响应结构。
• 只在 admin dashboard 读路径上增加短 TTL 缓存与并发合并。

本地验证

单元/静态检查

• docker run --rm -v /home/ius/sub2api/backend:/src -w /src golang:1.26.1 /usr/local/go/bin/go test ./internal/handler/admin -count=1
• docker run --rm -v /home/ius/sub2api/backend:/src -w /src golangci/golangci-lint:v2.9.0 golangci-lint run --timeout=30m

Docker 烟测

• docker compose -f /tmp/sub2api-prtest-compose.yml up -d --build
• 登录成功：POST /api/v1/auth/login 返回 200
• 接口验证：
  • GET /api/v1/admin/dashboard/trend 返回 200
  • GET /api/v1/admin/dashboard/users-trend 返回 200
  • GET /api/v1/admin/dashboard/snapshot-v2 返回 200
• 缓存验证：首次请求 X-Snapshot-Cache: miss，再次请求 X-Snapshot-Cache: hit

CI

• fork 分支 fix/dashboard-read-pressure-20260311 的 CI 已通过
• fork 分支 fix/dashboard-read-pressure-20260311 的 Security Scan 已通过