Improve provider attribution in request monitoring

[SHIJIU6]

Summary

• Preserve usage aliases from the usage service so provider routing prefixes stay visible in monitoring views.
• Attribute masked provider API key usage back to configured provider prefixes and base URLs.
• Show provider details in the account overview and realtime monitor table with localized labels.
• Keep realtime rows grouped by the same provider source while preferring prefixed account labels.

Validation

• npm run type-check
• npm run lint
• npm test -- src/pages/MonitoringCenterPage.test.tsx src/features/monitoring/hooks/useMonitoringData.test.ts src/features/monitoring/accountOverviewState.test.ts

[seakee]

感谢这个 PR，provider attribution 这个方向我是认可的。多 provider / 多 prefix 场景下，监控页确实需要更清楚地展示请求来源。

不过结合 v1.2.1 已经引入的 api-key alias 设计，我不建议当前版本直接合并，需要调整后再合并。

v1.2.1 里 alias 的语义已经是：

api_key_hash -> 用户自定义 API key 展示别名

所以这个 PR 里新增的 usage alias 容易和现有 api_key_aliases.alias 混淆。这里实际表达的是 usage/routing alias，建议不要继续叫 alias，可以改成 usage_route_alias、route_alias 或 provider_route_alias。

另外，持久化方式也建议和 v1.2.1 的设计对齐。v1.2.1 是通过独立的 api_key_aliases 表，以 api_key_hash 作为稳定关联字段来保存用户别名，而不是把别名混进 usage raw data 或前端临时推导。这个 PR 如果需要长期保存 provider attribution / routing alias，也建议采用类似的结构化持久化方式，例如基于 api_key_hash 或明确的 provider key hash 建立稳定映射，而不是依赖 raw_json 里的 alias 或 masked source 反推。

当前默认展示的信息也偏多了。按 v1.2.1 的设计，监控页主展示应该优先是用户设置的 api-key alias / account label，而不是 provider、baseUrl、usage alias 这些技术细节。建议展示层收敛为：

主标题：api-key alias / account label
辅助信息：provider prefix / provider 类型
详情/tooltip：baseUrl、usage route alias、masked source、hash

也就是说，provider prefix 可以展示，但不建议拼进账号主名称；baseUrl 和 usage alias 原文不建议默认铺在账号概览和实时请求列表里。

实现上也建议调整几个点：

1. provider 归因优先使用 api_key_hash，masked source 只作为 fallback，避免误匹配。
2. alias prefix 提取规则需要收紧，不要对任意包含 / 的字符串都取 prefix，最好只匹配已配置 provider prefix 或 prefix/m:*、prefix/k:* 这类明确格式。
3. 不建议在 RecentEvents / BuildPayload 这类热路径里反复解析 raw_json。如果要长期保留 routing alias，应像 v1.2.1 的 api-key alias 那样结构化持久化；否则只作为 legacy fallback。
4. 需要补 Go 侧测试和完整检查。这个 PR 改了 Go 代码，合并前建议跑：

gofmt -w usage-service/internal/...
go test ./...
go build ./...
npm run type-check
npm run lint
npm run build
npm test

结论：功能方向可以接受，但当前实现和 v1.2.1 的 api-key alias 模型还没有完全对齐，尤其是命名、持久化方式和默认展示层级需要调整。建议先 Request changes，调整为“结构化持久化 + 轻量默认展示 + 详情中保留完整 provider attribution”后再合并。