API: pagination + filtering for the audit_log admin analytics endpoints

[Depo-dev]

Summary

Add time-range filtering, pagination, and aggregation to the audit_log-backed admin analytics endpoints.

Background & current behaviour

services/api/handlers/admin.go runs COUNT/range queries against audit_log for per-key analytics. There is no flexible time range, no pagination for detail views, and no aggregation (error rate, latency percentiles) for dashboards.

Why this matters for MVP

Operators and customers need usage/health dashboards. Fixed queries without ranges/aggregation can't power that.

Proposed implementation

1. Add query params: time range (from/to), api_key_id, endpoint; keyset pagination for detail rows.
2. Add aggregations: request count, error rate, latency percentiles (p50/p95/p99) per period/key/endpoint.
3. Ensure supporting indexes exist (coordinate with DB: review and add indexes for the audit_log analytics + admin queries #247) and attach EXPLAIN evidence.
4. Bound expensive aggregations (max range) to protect the DB.

Acceptance criteria

• Time-range + key + endpoint filters; keyset pagination.
• Aggregations: count, error rate, latency percentiles.
• Index-backed queries with EXPLAIN evidence; max-range guard.
• Tests for filters, pagination, and aggregation correctness.

Affected files / components

• services/api/handlers/admin.go
• database/migrations/ (indexes if missing)

Testing & verification

Handler tests with seeded audit rows asserting aggregates; EXPLAIN evidence in the PR.

Related / dependencies

Depends on audit_log indexes (#247); feeds usage metering (#300).

Out of scope

A billing system (metering data only).

---

Target branch

All work for this issue MUST target the dev branch. Cut your feature branch from dev and open the pull request against dev, never against main. Any PR opened against main for this issue will be closed and asked to re-target dev.