docs(register): C-83 — full-population hash sweep bounds the tampering residual

[Polichinel]

Amends the C-83 verification block. No entry added or resolved; header counts untouched. They read 64 / 12 / 52 on this base — C-84 landed between C-83 and this amendment, so the 63/12/51 I quoted earlier is stale.

The 2026-08-15 triage checked the eleven rows whose $updatedAt had moved, and predicted that hashing the remaining 572 would add nothing. Against substituted bytes that prediction held exactly — this does not correct it.

Every row was re-downloaded and re-hashed anyway:

collection	verified	mismatched	rows with no file	files with no row
unfao	111/111	0	0	0
production_forecasts	461/461	0	0	0

sha256, confirmed empirically across all 572 rather than assumed. Read-only, GET only.

What it adds

A fact a sampled method could not reach: rows and files are a perfect bijection.

That bounds the residual. A count-preserving delete-and-recreate must point its new row at a file that already exists, since the buckets were never writable. Pointing it at a file another row already claims leaves the displaced file referenced by nothing — an orphan. There are none, and there were no unreferenced files available to point at. So no file-level substitution is reachable by that route either.

What survives

A delete-and-recreate preserving fileId and file_hash while altering only descriptive fields — targets, name, description. Still unfalsifiable, for the reason the triage already gave. The verdict stands as written; its residual is now bounded to metadata semantics rather than file bytes.

docs/validate_docs.sh passes.