perf: 鉴权缓存让命中请求零 SQL，去掉两个无用索引

profile（16 并发）显示请求路径的 CPU 有 ~70% 花在鉴权上：每个代理请求都要用
密钥哈希查 api_keys、再用 user_id 查 users，两条随机读。

- 新增鉴权缓存（OT_PROXY_AUTH_CACHE_TTL，默认 2s，0=关闭）：缓存密钥与用户行，
  但密钥状态、用户状态、密钥过期仍按当前时间逐请求判定；管理端写操作与用户的
  密钥写操作经中间件立即清空缓存。余额随用户行一起缓存，只影响「≤0 就 402」
  这道软闸，最长滞后一个 TTL（请求照样计费）。
- last_used_at 节流改由缓存内的 touch 表记账（原先按 DB 行时间戳判断，行被缓存后
  时间戳不再变化，会导致每请求都写一次库）。touch 用 sync.Map：早先与缓存共用一把
  排他锁，16 并发下互斥饥饿把吞吐从 31k 拖到 3.2k（p99 7ms），换 sync.Map 后消失。
- 去掉 usage_logs 上从未被查询过滤的 key_id / trace_id 索引（没有查询按它们过滤，
  每个索引都是每行一次 B-tree 插入）；schema v8 迁移里显式 DROP 旧库上的索引。

实测（16 并发、mock 上游、SQLite）：
- 鉴权缓存开：p50 131–177µs、p99 0.6–1.2ms、RPS 56k–81k
- 鉴权缓存关：p50 535–631µs、p99 1.6–2.8ms、RPS 21k–27k
（4 并发下同样受益：30k→41k）

测试：新增缓存命中零 SQL、状态/过期重判、失效、TTL 到期、缓存关闭、并发七项；
go vet、go test ./...、-race（proxy/usage/store/api）全绿。

README.md

@@ -13,7 +13,7 @@
   - `GET /v1/models` — 可用模型列表：只列调用方真能用的模型（叠加用户与密钥白名单），带上下文长度与能力位；Anthropic 客户端（带 `x-api-key`/`anthropic-version`）返回 Anthropic 形状
   - **三协议互转**：客户端协议 × 渠道协议不匹配时自动转换（如 Chat 调用 Claude、Messages 调用 OpenAI、Responses 调用 Claude），流式逐事件转换；协议匹配时直通
   - 错误按客户端协议返回（OpenAI 格式 / Anthropic 格式）
-- **热路径开销**：模型/渠道目录进程内缓存（每请求 SQL 从 10 条降到 2 条，管理端写操作与健康状态变化即时失效）、流式正文按字节快路径提取、请求体定点改写（模型映射不再整包 unmarshal/marshal）、tiktoken 编码器复用、会话亲和表 16 片无锁竞争（键为 64 位摘要、零分配）、访问日志走 64 KiB 缓冲（不再每请求一次 stderr 系统调用）；记账落库按驱动自适应（SQLite 单 worker + batch 64，并启用 `_txlock=immediate` 与 `synchronous=NORMAL`，实测 13k → 30k rows/s 且抖动从 ±50% 收敛到 <1%；PostgreSQL 4 个分片 worker）
+- **热路径开销**：鉴权缓存（`OT_PROXY_AUTH_CACHE_TTL`，默认 2s，缓存密钥+用户行，状态与过期仍按当前时间判定，写操作即时失效）——开启后命中请求**零 SQL**，16 并发实测 p50 535µs→131µs、RPS 21k→56–81k；模型/渠道目录进程内缓存（每请求 SQL 从 10 条降到 2 条，管理端写操作与健康状态变化即时失效）、流式正文按字节快路径提取、请求体定点改写（模型映射不再整包 unmarshal/marshal）、tiktoken 编码器复用、会话亲和表 16 片无锁竞争（键为 64 位摘要、零分配）、访问日志走 64 KiB 缓冲（不再每请求一次 stderr 系统调用）；记账落库按驱动自适应（SQLite 单 worker + batch 64，并启用 `_txlock=immediate` 与 `synchronous=NORMAL`，实测 13k → 30k rows/s 且抖动从 ±50% 收敛到 <1%；PostgreSQL 4 个分片 worker）
 - **渠道体系**：按模型绑定选渠道 + 加权负载均衡；模型已有绑定时只用绑定渠道（都不可用则 503，不会把请求发给不认识它的渠道）；每渠道并发信号量（满载排队 `OT_PROXY_CHANNEL_ACQUIRE_WAIT`，默认 150ms，仍满则 503 + Retry-After 而不是 502）；后台健康检查（探测 `/models`，连续失败进 cooldown、恢复放回）+ 运行期健康（按失败原因分类冷却：网络错误/5xx 连续 3 次进冷却且指数退避，余额/配额类第一次即冷却 30 分钟，成功清零退避计数）；可安全重试的失败自动故障转移（网络错误/429/5xx/超时/流式首个内容事件之前的任何失败）；**会话亲和**（`OT_PROXY_AFFINITY_TTL`，默认 5m）：同一会话粘住上次应答的渠道，命中上游提示词缓存而不是全价重算，冷却/下线自动回退加权随机
 - **上游超时**：渠道 `timeout_ms` 生效——非流式为整段请求上限，流式仅约束首包（正文不限时长）；上游请求绑定客户端 context，断连即取消
 - **故障转移与流式细节**（借鉴 magpie 的 holdWriter）：流式请求在**首个内容事件**到达前由网关缓冲——上游的错误事件、空流、断连、协议形态不符（要流给了整包，didNotStream）都在放行前换渠道消化，客户端无感知；`OT_PROXY_FIRST_TOKEN_WAIT` 限定放行前等内容的最长时间（0=不限）；429 不一定是限流——错误体带余额/配额特征时按配额类长冷却；上游 `Retry-After` 会延长该渠道冷却（夹在 10 分钟内）；重试受 `OT_PROXY_FAILOVER_BUDGET` 时间预算约束（首个渠道不受限，避免坏渠道把客户端拖到 N×timeout）；流式空闲超过 `OT_PROXY_STREAM_HEARTBEAT` 补一行 SSE 注释心跳（扣住期间也照发），防止 nginx/Cloudflare 的空闲超时掐掉长思考；响应头已被心跳先行写出时，全部候选失败以 SSE 错误事件收尾