Fix silent 100-row cap in API-key analytics and summary

[nicolasgutierrezdev]

Summary

get_user_summary and get_usage_analytics added up usage rows in Python, working from the result of fastcrud's get_multi. That call returns at most 100 rows by default, so every metric was silently wrong once a key or user had more than 100 usage rows.
get_multi. That call returns at most 100 rows by default, so every metric was silently wrong once a key or user had more than 100 usage rows.

Changes

• get_user_summary: total_cost_microcents now comes from a SQL SUM (new sum_user_usage_cost). It used to cover only 100 rows while total_requests counted all of them.
• get_usage_analytics: totals, the top endpoints, the error breakdown and daily usage are now computed in SQL with COUNT, SUM, AVG and GROUP BY.
• api_keys/utils.py: removed, since nothing uses the Python aggregation helpers any more.
• Tests: added tests that check nothing is capped at 100 rows, that the cost sum only includes the given user's usage, and that rows outside the date window are excluded.

Testing

I added 150 usage rows to one key and comparode, in unit tests and on both versions ofthe app running live:

Field	Before	After
summary total_cost_microcents	100,000	150,000
analytics total_requests	100	150
failed_requests	0	50
error_breakdown	{}	{"500": 50}
usage_by_day	2 days	3 days

Follow-up (not in this PR)

get_user_summary gets keys through get_user_api_keys, which returns at most 50. That caps total_keys and active_keys at 50.