Analytics Status tabs: per-tick query + client-side aggregation cost (free-tier load; UI vs core vs aggregation service)

Tracking issue consolidating the performance / architecture question raised on #1506, since it's cross-cutting across the analytics Status work rather than specific to one PR.

### The concern (from #1506)
> is it possible the analytics stuff is bringing down instances in the free tier? I have a very minimally used free cluster in stage, and I swear when I navigate to the analytics status stuff, it goes down. I'm talking cross PRs. What is this costing us from a performance perspective? Are we solving problems in the UI that should be solved in core, or should be solved in an analytics aggregation service?

### What we saw during local review
While browser-verifying #1506 against a stage instance, switching the **Health** tab to **Last 7 days** produced **13× `AxiosError: timeout of 60000ms exceeded`** in one window slide. The whole tab fires `get_analytics` POSTs per refresh tick — one per metric panel (5 on Health) plus the new KPI strip's queries in #1506 — and wide ranges make each query heavy. At 1 hour it's fine; the cost scales with range width and panel count. All the cluster-aggregation math (per-scope p95, count-weighted means, cross-node sums, error-rate projection) runs **client-side** on the raw records the instance returns.

So: every Status-tab view is N concurrent analytics queries + client-side aggregation per tick, repeated on the refresh interval. On a small/free-tier node that's a plausible source of the load the free cluster shows.

### Questions to triage (as you see fit, @kylebernhardy)
1. **Cost:** what is the real per-tick / per-tab cost on the instance — query count, payload size, and Harper-side work — especially on the smallest tiers? Is the refresh cadence × panel count × range sustainable there?
2. **Where should aggregation live:** are we computing things in the UI that belong in Harper core, or in a dedicated analytics aggregation / rollup service that serves pre-aggregated series? (The client currently pulls raw records and reduces them.)
3. **Client-side mitigations in the meantime:** coarser buckets / fewer points on wide ranges, capping concurrent panel queries, backing off after a timeout, or gating auto-refresh when a tab isn't visible.

### Scope
Not a blocker for any single PR — a direction call for the analytics feature area. Recent additions that touch this surface: #1506 (adds KPI-strip queries to the Health tab) and #1507 (rendering-only — `syncId`, no new queries). Filing so the question is tracked and owned rather than living in a PR thread.