[Bug]: 请求监控历史账号因 CPA auth_index 变更显示为脱敏来源

[seakee]

部署方式

CPA 控制面板 + 外部 Usage Service

CPA 版本

包含 41f4ee7c 之后的版本，或从旧版本升级到该版本后出现

CPA-Manager 版本

v1.1.8

问题描述

CPA 升级后，请求监控中今天的新调用可以正确显示账号，但历史调用显示为脱敏的 m:... / 脱敏邮箱，无法判断具体哪个账号产生了花费。auth file 当前仍然存在，但 CPA-Manager 只能按 usage 事件中的历史 auth_index 精确匹配当前 /v0/management/auth-files 返回的 auth_index。CPA 的 auth_index 是运行时派生字段且不持久化，CPA commit 41f4ee7c 修改了 auth index seed 规则，导致历史 usage 记录中的旧 auth_index 与当前 auth file 的新 auth_index 不一致。

补充信息：

• CPA Auth.Index 是 json:"-" 运行时字段，不持久化。
• CPA usage queue 只传 auth_index，不传 auth_id。
• CPA-Manager usage-service 已将 source 脱敏入库，因此匹配失败后无法可靠反推账号。

复现步骤

1. 使用旧 CPA 版本产生请求监控数据。
2. 升级到包含 CPA commit 41f4ee7c 的版本。
3. 打开 CPA-Manager 请求监控 / 账号汇总。
4. 查看升级前历史调用。
5. 历史调用无法关联到当前 auth file，账号显示为脱敏来源。

截图

修复范围

1. 历史兼容

   • CPA-Manager 对 CPA 旧版 auth_index 生成规则做 alias 匹配。
   • 不修改 usage_events 原始 auth_index。
   • 只做高置信映射，避免误归属花费。

2. 入库快照

   • Usage Service 在写入 usage_events 时保存账号展示快照。
   • 快照字段用于后续展示兜底，避免 auth_index 再次变化后丢失账号信息。
   • 不保存原始 API key/token，只保存可展示的 account/label/file/provider 信息。

3. 兜底能力

   • 对既无法 legacy alias 匹配、又没有 snapshot 的历史数据，后续提供手动绑定方案。

检查清单

• 我已经搜索过现有 Issues，没有找到重复问题
• 我已经确认敏感信息已经脱敏，例如 token、key、账号信息