tc_013's census floors are stale by ~2.7x and would not catch a narrowing

[kreneskyp]

Raised in the review of #127 and recorded rather than folded in — the block is byte-identical on origin/main and #127 provably does not change the census result set (both walkers return the same 223 files on a clean tree).

Measured

tests/shared_assurance.rs tc_013. Instrumented to print the real values against the declared ones:

scope	declared floor	comment claims "measured"	actual
total inspected	27	30	82
.github	1	2	3
schemas	2	2	7
src	4	4	26
tests	4	5	29

Correct as declared: <root> 9, assurance 2, examples 1, scripts 5.

Why it matters

22 of 26 src/ files and 25 of 29 tests/ files could vanish with the gate still green. The 45 - 15 = 30 arithmetic in the comment no longer describes the tree.

More specifically, this sentence in that same comment is now false:

this floor is not the instrument that catches a directory disappearing: the set comparison and the per-directory floors below do that, and they trip on losses far smaller than 4

The per-directory floors do not trip on losses far smaller than 4 — they have roughly 6x, 3.5x and 6x of headroom in src, schemas and tests respectively. Today the only load-bearing assertion in that block is the found == expected directory-set equality check: it catches a directory disappearing, but nothing catches files draining out of a directory that still exists.

This is the repo's own organizing defect class — a criterion too weak to fail — sitting in the census that polices the deleted evidence framework.

Asked for

1. Re-derive the floors and the per-directory counts from the current tree, and correct the arithmetic in the comment so it describes the tree it is measuring.
2. Correct or delete the sentence quoted above, which states a property the floors do not have.
3. Decide deliberately how much headroom a floor should carry. A floor that tracks the exact count goes red on every legitimate file addition; one with 6x headroom catches nothing. Whatever is chosen, say which it is and why, so the next reader does not have to measure it to find out.

Not claimed

No evidence that any file has actually gone missing — the directory-set equality assertion still holds and the census result set is unchanged from origin/main. This is about what the gate could catch, not a live loss.