feat(caller-drift): the conformance matrix — one screen, coverage as well as drift (backend#1608)

[LukasWodka]

What

#1608 increment 3 — the "one screen". The harness has had teeth since required_checks and rulesets landed; what it never had was a view.

Why

The audit has always known every repo's state per family and only ever emitted the failures. A green run said "No drift. Every repo read, every entry matched" — and nothing about what was covered. You could not tell a fleet that conforms from a fleet that was barely checked.

That is the same question this epic keeps finding the wrong answer to elsewhere: a caller that is present but advisory, a required check that never reports, a scanner that never ran. The report had the same blind spot as the things it audits.

The screen

A per-repo × per-family table in the report — callers, copies, protection, rulesets, all 20 repos, train flag alongside:

| repo | train | callers | copies | protection | rulesets |
|----------------------|-------|---------|--------|------------|----------|
| `.github` | yes | OK | OK | OK | OK |
| `backend` | yes | OK | OK | OK | OK |
| `claude-skills` | - | OK | OK | OK | OK |
...

Cells are deliberately three-valued:

cell	meaning
OK	evaluated and matched
N	that many findings
?	that family could not be read

? is the point. "Zero findings because we checked" and "zero findings because we never looked" must not render the same — the whole guard exists to refuse that conflation, so the screen refuses it too.

Counted by delta around each family's block, not by parsing the finding strings. Those strings are prose written for humans; keying a table off them would break the first time one is reworded.

Test plan / evidence

check	result
live, all 20 repos	renders 20 × 4, every cell OK, exit 0
mutation — impossible required-check in the develop baseline	protection column shows 1 for exactly the 16 train repos, OK for the 4 non-train ones whose develop role is exempt; exit 1
selftest	116 → 122, 0 fail
ruff --isolated --select E4,E7,E9,F	All checks passed!

The mutation row is the one that matters: a screen that can only ever render OK is precisely the vacuous pass this guard exists to refuse. It shows red — and shows the shape of the failure: one family, one cohort, visible without reading a single finding line.

The selftests lock the states the live fleet cannot produce: an unreadable repo (? across the row), an unreadable family (? in that column only), and — the one that would be easiest to regress — that a clean row and an unread row do not render identically.

Parent epic: backend#1680 · closes #1608 increment 3.

---

Note

Low Risk
Reporting-only change to an audit script; counting logic is additive and covered by new selftests, with no change to pass/fail exit semantics described in the diff.

Overview
Adds the “one screen” conformance matrix to the caller-drift GitHub step summary so reviewers see coverage and drift together, not only a failure list on green runs.

During each repo audit, the script now builds a matrix keyed by repo and family (callers, copies, protection, rulesets). Finding counts come from deltas on findings (and protection/ruleset unread lists) around each family’s evaluation block—not from parsing finding prose. Unreadable repos get a full-row ?; protection/rulesets can show ? in a single column when only that layer failed to read.

New render_matrix() emits a collapsible markdown table (repo, release-train flag, four families) with OK, bold counts, or ?, inserted into the report before the detailed finding bullets.

Selftests lock matrix rendering: clean rows, counts, full vs per-family unread, and that “checked clean” ≠ “never read”.

^{Reviewed by Cursor Bugbot for commit c8f8e04. Bugbot is set up for automated code reviews on this repo. Configure here.}