docs(backlog): record the leak-gate six-digit review, verdict leave it (BACKLOG #1436)

[wshallwshall]

One commit, docs/BACKLOG.md only. No detector was changed — this is the finding, not a fix.

Verdict: leave the rule alone, and the asymmetry settles it

The reported defect does not exist as described. The claim was that the leak gate flags any bare
six-digit number as a site code. It does not:

• _ESTATE_ID_SHAPE needs the six-digit run welded into an underscore-joined identifier, and matches
  0 lines across 2,038 tracked files.
• _SITE_CODE_FILE fires on a bare six-digit run only when its leading digits match a loaded
  [site_prefix] value, of which two load.
• Run as configured over the whole tracked tree, scripts/security/scan_forbidden.py flags
  zero lines and exits 0.

So the friction the "a control everyone routes around is not a control" argument depends on is not
there when measured. Per hypothetical two-digit prefix: median 1 blocked commit in 350, max 6.

The block that prompted this was a true positive, not a structural false one — the timeout
constant's leading two digits are a real loaded site prefix.

Narrowings tested, against 12 constructed true positives

narrowing	true positives missed
require the underscore anchor	8 of 12
drop runs ending 0000	3
drop runs ending 000	3
require adjacent context	4
shipped pair	0

The most plausible narrowing also merely re-derives a detector that already ships, deleting the
token-loaded detector's entire reason for existing: reaching codes in HL7 fields, prose, quoted
config values and CSV cells. There is no trade available.

Populations, measured at 46ea10a78

Using the scanner's own file walker, skip sets and allowlist rather than a second definition.

population	lines	files
bare delimited six-digit runs, ungated	1,199	136
same, over the population _SITE_CODE_FILE sees	379	129
_ESTATE_ID_SHAPE	0	0
the gate as configured, whole tree	0	0

Positive control: the same loop returned 1,619 / 1,199 / 453 lines at widths 5 / 6 / 7 and 0 for
a nonsense token, so the estate-shape zero is a real zero and not a broken query.

Third paths, and why they are displacement

The documented allowlist already exists, with a canary guard, already carrying an entry for exactly
this false-positive class. A per-hit reason naming the loaded set was already declined under #322.

The one real gap: the text explaining this class lives only in scan-tokens.local.txt.example, under
a heading scoped to running the synthetic set, so a maintainer on the real list reads it as somebody
else's problem. That is the remaining scope — one paragraph in CONTRIBUTING.md.

Disclosure

While measuring, the reviewer ran the scanner's --show-context flag once, and it echoed a real
token value into that session's transcript. The scanner's own docstring says that flag is never used
in CI for exactly this reason. It was one run against a scratch probe file outside the repository;
the value reached no tracked file, no commit and no pull request, and every later run was
reasons-only. No concrete six-digit value was written into the backlog item, since a placeholder
built from a loaded prefix is itself a hit.

Checks

ruff reported "no files to check" — the diff touches no Python. Passed at commit time: ledger gate,
backlog-parses, forbidden-content, control-characters, username-access-key screen, gitleaks. Also run
by hand: backlog_status_check.py, backlog_citation_check.py, verdict_divergence_check.py, and
link_check.py (4,800 links, all resolve).

🤖 Generated with Claude Code

[wshallwshall]

Disclosure: the reviewed label on this pull request was applied by the Manager seat that commissioned the diff.

It is not an independent read of the scope. COMMON.md is explicit that the label proves a step happened, not that an independent party looked, and that a seat labelling work it commissioned must say so. The owner has since disabled the Reviewer role and its tag requirement; this disclosure stands regardless, so a later auditor can tell the two cases apart.

What I actually checked, so the record is specific rather than a blanket claim:

• Confirmed the diff is docs/BACKLOG.md only, and that no concrete site-code value was written into the item.
• Ran a glyph scan on the added lines with an injected control proving the scanner discriminates on this exact diff.
• Rebased this branch onto current main myself and resolved the ledger conflict, verified with parse_items.

I did NOT re-run the scanner population counts; the zero-of-2038 and 12-true-positive figures are the reviewer's.