metrics_coverage denominator counts retro bookkeeping issues, so a blackout-report-only window can never reach 1/1

Observed class

The retro digest's metrics_coverage line is computed as usable metrics rows / closed issues in the window. The closed-issue set is not filtered by whether the issue represents agent delivery work. Retro bookkeeping issues — the blackout report the retro itself creates when coverage is 0/N — are closed issues too, and by construction no collector row can ever exist for them (no agent work ran; the collector only emits rows for dispatched agent runs).

Consequence: on a consumer whose only recent closed issues are blackout reports (exactly the state a prolonged blackout produces), the coverage line is structurally pinned at 0/1 even after the collector is fixed and wired. The first post-fix window still reads 0/1, because the denominator still contains the stale blackout report. The signal meant to prove recovery cannot show recovery.

Evidence from this window

• Window 2026-10-25T23:38:20Z → 2026-10-28T02:24:42Z on a consumer repo: metrics rows 0, closed issues 1, and that one issue is the blackout report itself ("Second consecutive metrics blackout: retro blind, collector never produced a row"). metrics_coverage: 0/1.
• Even a perfectly wired collector could not have produced a row for that issue: nothing was dispatched for it. The 0/1 therefore mixes two different facts — "the collector produced no rows" (true, collector defect) and "one closed issue has no row" (unavoidable, bookkeeping issue) — into a single ratio.

Proposed implementation plan

1. In the digest builder, classify each closed issue in the window as delivery vs bookkeeping (bookkeeping = issues created by the loop's own machinery: retro blackout reports, retro reports, escalation placeholders). The label already distinguishes boucle:retro / boucle:report from work issues, so the classification can key off labels rather than new state.
2. Compute metrics_coverage over the delivery subset only: usable metrics rows / delivery issues in window. Report bookkeeping issues separately (e.g. bookkeeping: 1 (excluded from coverage)).
3. Keep the blackout WARNING trigger as-is (any closed delivery issue with no row), but suppress the warning when the delivery count is 0 and only bookkeeping issues closed — that state means "the loop is quiet", not "the collector is blind".
4. Acceptance criteria:
   • A window whose only closed issue is a blackout report shows metrics_coverage: 0/0 (or n/a) with the bookkeeping annotation, not 0/1.
   • A window with 2 delivery issues and 1 usable row shows 1/2, unchanged from today.
   • The blackout WARNING fires only when a delivery issue lacks a row.
   • Existing digest consumers (retro prompt, CI checks) parse the new shape without error.

Size

Size: S