[GavinKung]

A populated usage overview currently runs 23 SQL statements even when the live window is empty. Repeated percentile scans and duplicate model aggregation make the dashboard slow as usage history grows.

Reduce a populated PostgreSQL overview to 12 statements. Compute exact nearest-rank percentiles with percentile_disc during the totals, trend, and ordinary ranking aggregations; share the grouped model results between request-count and token-count rankings. Keep the existing credential pre-aggregation so auth resolution operates per credential index. The live summary now reads only the usage counters and latencies it returns.

The API response and accounting rules remain unchanged. SQLite retains its existing percentile implementation and benefits from the smaller live query. There are no schema migrations, new query goroutines, database setting changes, timeout increases, or CPA/HMC contract changes. Large ranges still require work proportional to their matching records; these measurements are not a production latency guarantee.

Validation:

• PostgreSQL 17 integration tests compare every top group, model-efficiency ranking, and overall/bucket percentiles against the previous SQL paths, including missing billing rows, credential aliases, legacy/v2 accounting, filters, empty ranges, half-open boundaries, and cancellation.
• A query-count regression fails on the original implementation (23 queries) and passes with the new implementation (at most 12).
• SQLite and PostgreSQL live-summary regressions cover accounting totals, the 300-second window, failure rates, zero/negative latency, and empty results.
• Focused overview/live tests pass, and Home compiles with go build -o test-output ./cmd/home && rm test-output.
• An isolated PostgreSQL 17 fixture with 500,000 usage rows and 400,000 charges, 7-day range, 2 CPUs, and 768 MiB memory was measured with before/after queries interleaved on the same database. Database planner settings were unchanged; automatic vacuum was disabled only on the disposable fixture tables and a checkpoint completed before timing. Three old runs: 5.720s / 9.366s / 5.986s. Three new runs: 4.930s / 5.155s / 5.634s. Median improvement: about 14%, with roughly half as many SQL round trips.

Fixes #81.
Fixes #158.