Gathering and surfacing operational metrics for a longer period of time #612

The problem

The console can only show what happened in the last hour, and only what it saw itself. The daemon keeps no history: the console builds its charts by counting the events it holds, so a reload starts them from zero. Several figures an operator needs to judge the fleet are not sent by the daemon at all.

This came up in the console redesign (#610). The figures below were in its design and were left out, because no API serves them today.

Who runs into this

Operators of a device cloud (one host or a gateway with workers) who want to know whether they have enough capacity, why agents wait, and why a device was taken out of use.

What you would like to happen

The daemon gathers these figures, keeps them over a longer period, and serves them. The console shows them.

1. Queue wait time (p95). How long lease requests waited before they got a device, over a time window. Shown as an Overview stat tile and on the Waiting page.
2. Leases per hour. How many leases were granted over a time window. Shown as an Overview stat tile. Today the console counts it from its own events, so it resets on every reload.
3. Where a waiting request could run. For a queued request: which workers match it, and why each one can't take it now (full, drained, wrong platform, no matching runtime). Shown in the Waiting inspector.
4. Quarantine reason. Why a device was quarantined, not only that it was. Shown in the Attention inspector.
5. 6h and 24h ranges. The lease, queue and capacity charts can switch beyond the last hour. This needs the daemon to keep a time series (for example per-minute counts), which also survives a console reload.

Anything else

• Open questions for the spec: how long to keep the data, where it is stored, and whether a gateway gathers it from its workers or computes it itself.
• Today's limit is written down in the console manual (ui/AGENTS.md, Known gaps: "No history beyond the last hour").