Extend the KPI views: utilisation, intervention rate, mission success rate, MTBF/MTTR

[Minipada]

What to build

#304 established where KPI definitions live (tools/infrastructure/sql/kpi_views.sql), how they
reach a database, how they are tested and how they are charted — and shipped exactly one metric
through that path: availability and uptime. This issue finishes the starter set.

The conventions are set and should not be re-litigated: dc_kpi_* naming, one view that
normalises the wide dc table per Measurement, the window as a function argument so a panel
reports the range on screen, a bucketed view for charting, a fixture test that seeds a known
Record sequence, and panels added to the provisioned dc-kpi dashboard.

View	Reports	Reads Records from
Utilisation	Productive time over available time, per robot per window	driving_type and speed — both already collected
Intervention rate	Interventions per hour of autonomous operation, and per kilometre	intervention, driving_type, distance_traveled
Mission success rate	Completed, failed, cancelled and aborted missions as a share of missions started	the Mission Measurement
MTBF / MTTR	Mean time between failures and mean time to repair	the fault Measurement (#365)

Two prerequisites are worth stating plainly rather than discovering during implementation:

• Mission success rate cannot land before the Mission Measurement exists, whose contract is
  still being agreed in Agree the mission lifecycle contract for the Mission Measurement #305. Utilisation and intervention rate do not depend on it.
• Nothing currently emits fault raise and clear events, so MTBF and MTTR have no source
  until the fault Measurement in Add Measurement: fault — raise and clear events from diagnostics, so MTBF and MTTR have a source #365 lands. diagnostics records snapshots, not transitions,
  and reconstructing a transition from snapshots gives a wrong duration whenever a Record is
  dropped.

Definitions that are honest about what they cannot see beat definitions that look complete.
Availability in #304 documents that a robot silent since before the window drops out rather than
reading 0 %; the same standard applies here — open intervals, missing denominators and
mission-less windows get documented behaviour, not a plausible-looking number.

Acceptance criteria

• A utilisation view: productive time over available time, over an arbitrary window, per robot
• An intervention-rate view, normalised per hour of autonomous operation and per kilometre travelled
• A mission success-rate view, with outcomes broken out rather than collapsed to a single ratio
• MTBF and MTTR views, over the fault Measurement's raise and clear Records
• Every view follows Starter KPI views and a provisioned Grafana dashboard #304's conventions: dc_kpi_* naming, the window as a query parameter, CREATE OR REPLACE, no dependency on the demo's specific deployment
• Open intervals (a mission or intervention still running) are excluded or explicitly handled, never treated as zero duration
• The fixture test (tools/infrastructure/test/test_kpi_views.py) gains a case per metric, seeded with a known Record sequence — this is where a definition change must break a test
• Panels for each metric on the provisioned dc-kpi dashboard, populated by the demo stack
• doc/src/dc/kpi_views.md documents each metric's definition and what it deliberately does not claim

Blocked by

• Add Measurement: intervention — human takeovers derived from driving-mode transitions #362
• Add Measurement: fault — raise and clear events from diagnostics, so MTBF and MTTR have a source #365
• Agree the mission lifecycle contract for the Mission Measurement #305

[Minipada]

Merged into jazzy as 8912018 (#369). GitHub does not auto-close from a non-default base branch, hence closing by hand.

Shipped: dc_kpi_utilisation(), dc_kpi_intervention_rate() and dc_kpi_reliability() (MTBF/MTTR), each with its normalising view over dc, a bucketed view for charting, fixture-test coverage (10 → 29 cases) and panels on the provisioned dc-kpi dashboard.

One acceptance criterion is deliberately not met: the mission success-rate view. Its contract is #305, which states on its face that it is a design decision needing a human — a view written first would pin that contract from the reporting end. doc/src/dc/kpi_views.md carries a section explaining the gap. Once #305 lands, the view is a small follow-up on the conventions this PR now shares across four metrics.

The intervention (#362) and fault (#365) views return no rows until those Measurements exist; their fixture tests seed the Records directly, so a definition change breaks a test rather than a dashboard.