Refactor usage polling to paged APIs with legacy fallback

[zly2006]

中文

变更内容

• 将监控页的高频用量轮询从完整 /v0/management/usage 响应拆分为更小的接口请求：summary、accounts、api-keys 和 realtime。
• 保留旧后端兼容能力：分页接口不可用时仍回退到旧版 /v0/management/usage 数据结构。
• 刷新按钮和自动刷新现在会重新拉取 model prices、API key aliases、meta 和 usage 数据。
• 修复相对时间范围刷新时 end_ms 被初次 render 固定的问题，避免总 tokens 和预估花费在第一次刷新后不再更新。
• 增加 useUsageData 回归测试，覆盖 model prices 重新加载行为。

验证

• npm test -- --run src/features/monitoring/hooks/useUsageData.test.ts src/services/api/usageService.test.ts src/features/monitoring/hooks/useMonitoringData.test.ts src/features/monitoring/accountOverviewState.test.ts
• npm run type-check
• npm run lint
• npm run build
• 通过浏览器 CDP 验证手动刷新和 5 秒自动刷新都会发送新的 end_ms，总 tokens 和预估花费会随新数据更新。

English

Changes

• Split the monitoring page's high-frequency usage polling from the full /v0/management/usage payload into smaller summary, accounts, api-keys, and realtime requests.
• Kept legacy backend compatibility: when the paged endpoints are unavailable, the UI still falls back to the old /v0/management/usage payload shape.
• Manual refresh and auto refresh now reload model prices, API key aliases, meta, and usage data together.
• Fixed stale relative time ranges where end_ms was frozen after the first render, which could keep total tokens and estimated cost unchanged after the first refresh.
• Added a useUsageData regression test for reloading model prices.

Verification

• npm test -- --run src/features/monitoring/hooks/useUsageData.test.ts src/services/api/usageService.test.ts src/features/monitoring/hooks/useMonitoringData.test.ts src/features/monitoring/accountOverviewState.test.ts
• npm run type-check
• npm run lint
• npm run build
• Verified through browser CDP that both manual refresh and the 5-second auto refresh send a fresh end_ms, and that total tokens and estimated cost update with new data.

[zly2006]

@seakee could u please review?

[seakee]

@seakee could u please review?

Thanks for the PR.

The current PR does help alleviate the problems of slow loading, timeouts, and high frontend aggregation pressure on the request monitoring page under large data volumes. The subsequent refresh logic fix is also valuable, as it prevents the end_ms from being fixed under a relative time range, which would otherwise cause the token and cost statistics not to update after a refresh.

However, this PR affects the core data path of CPA-Manager request monitoring, so I’m not recommending merging it directly just yet. A few things still need to be addressed:

1. Although the paginated endpoint has already been split out, the /summary endpoint may still return a large number of details grouped by dimensions such as account, provider, model, api key hash, source, etc. When there are many combinations of accounts, models, and API keys, the summary itself could still become a large payload. I’d suggest making the summary return only top-level statistics and offloading all detailed/breakdown data to the paginated endpoint as much as possible, or at least adding a limit / lazy-loading parameter.

2. Please confirm that there is a hard upper limit for page_size on the backend to prevent excessively large values from causing internal DoS or putting too much pressure on SQLite. In addition, sort_key / sort_direction must be mapped through a backend whitelist and must not be directly concatenated from user-supplied values.

3. Currently, the search performs a LIKE "%term%" query across multiple fields, which could be quite slow under large data volumes. I’d suggest documenting the performance boundaries for a large time range combined with search, restricting the time range when necessary, or considering indexes / FTS optimization later.

4. GitHub is flagging hidden / bidirectional Unicode characters that need to be handled. Hidden Unicode characters should not remain in core code. Please clean them up or explain their specific source and impact.

5. At this point, the change is no longer just a frontend refactoring; it introduces a set of stable management APIs. Tests need to be added for summary, pagination, filtering, sorting, page size limits, legacy fallback, etc., to avoid discrepancies in request monitoring statistics down the line.

[zly2006]

thanks for your review, I will fix them