Fix API key identity in usage analytics

[AveryanAlex]

Summary

• Group usage analytics by stable api_key_id instead of mutable API key names.
• Preserve historical API key names as aliases while displaying the current key name when available.
• Update dashboard filtering and API manager usage lookups to match API keys by ID.

Testing

• node --import tsx/esm --test tests/unit/usage-analytics-route.test.ts tests/unit/usage-analytics.test.ts
• npm run typecheck:core
• npm run lint (passes with existing warnings only)
• Manual analytics route validation: renamed aliases collapse into one row with expected request/token totals.
• Manual testing by human: tested the fix in the app and it works as expected.

Notes

• npm run build could not complete locally before reinstalling dependencies because the checkout was missing docs packages: gray-matter, fuse.js, marked, and isomorphic-dompurify.

[gemini-code-assist]

Code Review

This pull request enhances API key usage tracking by grouping statistics by a stable apiKeyId, enabling consistent reporting across name changes and providing visibility into historical aliases. Key changes include updated SQL aggregations, metadata fetching for current names, and UI adjustments to use stable identifiers. Review feedback identifies performance optimization opportunities, specifically recommending caching or filtering the database fetch for API keys and utilizing a Set for historical name tracking to avoid O(N*A) complexity during aggregation.

I am having trouble creating individual review comments. Click here to see my feedback.

src/app/api/usage/analytics/route.ts (258)

Fetching all API keys from the database on every analytics request might become a performance bottleneck if the number of keys grows significantly. Consider passing the apiKeyIds filter to getApiKeys to only fetch the necessary metadata, or implement a short-lived cache for the full list of keys.

src/lib/usage/usageStats.ts (326-328)

Using Array.prototype.includes inside a loop over all usage history entries results in O(N * A) complexity, where N is the number of history entries and A is the number of historical names. While A is typically small, using a Set for historicalApiKeyNames during the aggregation phase would be more efficient (O(N)). You can convert the Set back to an Array once the loop is complete.