Starter KPI views and a provisioned Grafana dashboard

[Minipada]

What to build

DC produces Records but nothing that turns them into the numbers an operations team reports on. This slice establishes the whole path — Records already in PostgreSQL, a set of SQL views over them, and a Grafana dashboard provisioned from those views in the demo stack — using only data that existing Measurements already emit.

Start with availability and uptime, which the uptime Measurement already supports. The point of this slice is not the metric but the conventions: where view definitions live, how the dashboard is provisioned alongside the demo, and how a view is tested. Every later KPI slice adds panels and views to what this one creates.

Metrics are computed in SQL, never on the robot. The time window is a query parameter, so changing a definition is a view change rather than a fleet redeploy.

Acceptance criteria

• SQL view definitions live in the repository and are applied by the demo stack
• A view reports availability and uptime over an arbitrary time window
• A Grafana dashboard is provisioned automatically when the demo stack comes up — no manual import
• Bringing up the demo and opening Grafana shows a populated chart without further configuration
• A fixture test seeds PostgreSQL with a known Record sequence and asserts the view's output
• The docs describe how to point the views at a real deployment rather than the demo

Blocked by

None - can start immediately

[Minipada]

Shipped in #358, rebase-merged into jazzy as f4cad58.

Every acceptance criterion, and how it was checked:

• View definitions in the repo, applied by the demo stack — tools/infrastructure/sql/kpi_views.sql, mounted into PostgreSQL's init directory as 20_kpi_views.sql (after 10_init.sql, since the views need the tables). tools/infrastructure/scripts/apply_kpi_views.bash applies the same file to a database that already exists, which the init directory never touches.
• A view reports availability and uptime over an arbitrary window — dc_kpi_availability(from, to [, max_gap]), plus dc_kpi_uptime_samples under it and dc_kpi_availability_5m for charting. A Record vouches for the time back to the previous one, capped at a grace period and clipped to the window, so only a silence longer than that costs availability.
• A dashboard provisioned automatically — kpi.json, uid dc-kpi, picked up by the existing Grafana file provider. Verified by running Grafana 9.5.2 against this repo's provisioning: it listed the dashboard alongside Home and Robot with no import.
• A populated chart with no further configuration — all seven panels' queries, $__timeFrom()/$__timeFilter() macros included, were executed through Grafana's own /api/ds/query against seeded Records. Every one returned data.
• A fixture test seeding a known Record sequence — tools/infrastructure/test/test_kpi_views.py, 10 cases, run against a throwaway Podman PostgreSQL by tools/infrastructure/scripts/test_kpi_views.sh and by a new standalone kpi-views CI job. It applies the same SQL files into a schema of its own, so it also proves they apply cleanly.
• Docs for pointing the views at a real deployment — doc/src/dc/kpi_views.md: the apply script, read-only GRANTs, the datasource, and the single object that names the dc table if Records live elsewhere.

One limit is documented rather than hidden: a robot whose Records stopped before the window starts drops out of the result instead of reporting 0 %, because nothing in the database distinguishes it from a robot that was never deployed.

The rest of the starter set — utilisation, intervention rate, mission success rate, MTBF/MTTR — is #363, with the Measurements it needs in #360, #362 and #365.