backlog: archive #335, file #1002 for #105's renumber, re-derive the census

[wshallwshall]

Closes the ledger reconciliation the last three PRs deferred. Supersedes #105, which will be closed.

One operation, deliberately

The pieces cannot be split. Removing a closed-but-rowed item and adding a new rowed item both move the rank column and both change every census line, so two passes would each publish a wrong count in between.

What moved

Archived #335 out. Its work landed in #177; it carried a closed banner while keeping its ranked-table row, which is what broke the heading-to-row bijection. Moved verbatim to BACKLOG-CLOSED.md (60 lines, unedited) and its row dropped.

Filed #1002 — the AG-rig validation that PR #105 filed as #319. That number was never allocated through alloc.ps1, and #105 gave it no ranked-table row — so merging #105 as-is would have duplicated the item under a second number and left a rowless heading. #1002 is allocated to this worktree.

Added the AOAG-DEPLOYMENT.md note #105 carried, renumbered, and applied as a block rather than cherry-picked: main's copy of that file has moved 29 insertions / 23 deletions since #105 branched, so taking the file would have reverted main's newer content. The anchor slug was verified to resolve against the new heading character for character rather than assumed.

Re-derived all four census lines plus the sum-to assertion. Line 144 — "Every one of the 93 open items" — was seven out, not one. It is the line the recompute script does not emit, so it drifts on every filing, and it was last corrected in #178. Fixing it again without fixing the generator guarantees a third occurrence; that is recorded in the migration plan rather than papered over here.

Measured after

Using parse_items imported from backlog_status_check.py, never a hand-rolled scan (CLAUDE.md §11 — I wrote three hand-rolled checkers in one day and got three different wrong answers, the third falsely reporting three open items as closed):

items	101
OPEN	101
closed-in-file	0
live rows	101
open heading with no row	NONE
row whose item is not open	NONE
ranks	contiguous 1..101
all four census lines	sum to 101

The bijection now holds in both directions. A matching total alone would not have shown that — a closed-but-rowed item and a filed-without-a-row item cancel, and every total-only assertion passes while both sets are wrong.

One near-miss worth recording

My first attempt renumbered 235 ranks. The live table has 101; the file also holds a superseded 134-row 2026-07-10 table, and an unscoped renumber walked into it and continued the sequence. Reverted and redone with the renumber bounded to the live section, plus an assertion that the historical rows are byte-identical afterwards (verified: 0 changed rows at rank >= 100).

The gate would not have caught it. It reads item banners, not ranks.

Verified, including the guards this PR will not run

The pytest legs are gated on code == 'true' and .md is in the noncode allowlist, so for a docs-only PR they are skipped pre-merge and fire only on the push to main afterwards. Run locally instead:

• tests/test_cutover_slug_rot.py — the two-way prose ratchet, which sits exactly at its ceiling (54 of 54)
• tests/test_backlog_status_check.py
• tests/test_feature_map_claims.py

30 passed. Ledger gate OK at 288 items across both files (101 + 187). Leak gate exit 0 with real detectors armed (names=7, estate=13, site_prefixes=1).

Scoring note, easy to correct

#1002 is scored 6 / 4 / quick win / P2, anchored explicitly on #1003 (7/4) and stated in the row's own rationale: one value below because #1003 discharges four hardware-gated residuals where this discharges one documentation mandate; difficulty matches because it is the same rig, a failover and a failback. I checked it is not subsumed — #1003 covers #99/#98/#320/#351, none of which is the cross-subnet reconnect.

At least three items still carry banners that understate what shipped. Stated as "at least" on purpose: a sweep establishes the real count, and an enumeration would be the completeness claim §11 warns against.