backlog: file #1004-#1011 and recompute the census from open-bannered headings

[wshallwshall]

Authored by the ASVS-cleanup session; opened by the coordinator on the owner's push/merge authority. I verified it independently before pushing rather than taking the reported numbers.

Independent verification

Re-measured with the canonical parser (parse_items imported from scripts/docs/backlog_status_check.py), not a hand-rolled scan:

items	101
OPEN	100
closed in file	[335]
items with no banner	none
live table rows	101
open heading with no row	NONE
row whose item is not open	[335]
ranks	contiguous 1..101
Value / Difficulty / Tiers / Quadrants	each sums to 100

Shipped gate: OK - 287 backlog items, each declaring exactly one status.

This was a pre-registered prediction, not a post-hoc check. Before the filing began I sent that session the expected post-filing numbers and said a census line reading 101 should be treated as a failure signal meaning rows had been counted rather than open-bannered headings. It measured, reported, and matched on every field. Two independently-derived models agreeing is worth more than one derived twice.

It also corrected a pre-existing error

The published census read 93 against 92 open before this branch. It now reads 100 against 100. So this does not merely add items, it fixes a drift that was already live on main.

Known, deliberate, and NOT defects

• fix(test): pin the RecursionError contract without a real stack overflow (#1222) -- unreds main #335 is still row-not-open - the single remaining bijection break. That is the coordinator's archive pass, tracked separately, and is deliberately out of scope here.
• feat(#114): the outbound validate_startup hook, with its ledger banner (train) #327 is counted OPEN with its banner recorded stale-with-evidence, not flipped. Its work merged while its banner still reads not-started. The reasoning is worth keeping: a census must be reproducible from the record, not true about the world, and those two come apart exactly here. Flipping it is a closure judgment for whoever owns its remaining scope.
• At least three items now have banners that understate what shipped. Stated as "at least" deliberately - the sweep is what establishes the real count, and an enumeration here would be the completeness claim CLAUDE.md section 11 warns against.

One defect I am NOT fixing in this PR, and why

The fourth census line still reads 93 where the other three read 100: "Every one of the 93 open items is re-scored here".

This is the second occurrence of the same defect on the same line - corrected once already in #178 after the same finding. The cause is that the fix went to the output and not the generator: the recompute script rewrites the three lines it emits and has never touched the prose sentence, so every future filing re-introduces it.

I could not fix it here. The ledger gate correctly blocked me: #1004-#1011 are allocated to the authoring session's worktree, and the gate diffs against main, so any commit I make on this branch reads as introducing eight numbers I do not hold. That guard exists because two sessions adding the same number land far apart in one 6.7k-line file and merge clean. Working around it with --no-verify was not an option. It follows in the coordinator's archive pass, where the line will be re-derived along with everything else.

Gates run locally because this PR will not run them

The pytest legs are gated on code == 'true' || push, and .md is in the noncode allowlist - so on a docs-only PR they are skipped pre-merge and fire only on the push to main afterwards. For a 1,219-line prose addition that matters, so I ran them here:

• tests/test_cutover_slug_rot.py - the two-way prose ratchet (_PROSE_CEILING = 54, with a companion test that fails if the ceiling has unused slack). Green.
• tests/test_backlog_status_check.py. Green. 21 passed.

Worth flagging on its own: a docs-only PR merging green and then turning main red is a live gap, not specific to this change.