docs: register int4-rans256-g0 in FORMATS.md; registry parity for ordinal-less rows

[monotophic]

Authored by Fable 5 in Claude Code, analysis in partnership with @monotophic.

Registers int4-rans256-g0 — the entropy-coded container format that merged
with #671's offline tools — in docs/FORMATS.md, and extends the registry
parity test so rows like it are inside the safety net.

Scope and audience: this changes no runtime behavior and affects no one's
tok/s. It's coordination infrastructure for format authors — the registry
exists because ordinal collisions happened twice in one month (#465 vs fmt=6;
#705 vs #528 on fmt=7, which cost a 191-reference renumber), and with CUDA
work now building on registered formats (#817), name/ordinal coordination is
load-bearing rather than hypothetical. Two concrete protections ship here:
the collision safety net now actually sees ordinal-less rows (it previously
skipped them — a colliding row passed CI green), and anyone who runs the #671
repack tools gets an explicit statement that pointing today's engine at a
repacked directory is unsupported, with the failure mode named instead of
discovered.

The row claims no public ordinal, deliberately. The format has no engine
decode path today (qt_resolve_fmt has no branch for it; no compiled fmt
constant exists anywhere, not even a private-block one — its identity is the
mandatory __metadata__["colibri.fmt"] stamp). Per this registry's own "ID
assignment" rule, an ordinal is claimed by the first merge into dev that ships
it; the row reads that as ships engine code consuming it for a
stamp-identified format — stated in the row as its own clarifying gloss, since
there is nothing to compile a number into until the ladder's PR 2 (engine
decode stage) lands. The "next free public ordinal is 9" statement stays true.

Registry parity coverage (c/tests/test_formats_registry.py): the parser
previously recognized only numeric-ordinal rows, so an ordinal-less row was
invisible to the collision checks this registry exists for. It now parses both
populations and enforces three rules on ordinal-less rows: name uniqueness
across the whole table, no claiming a compiled FMT_NAMES name, and an
explicit "no public ordinal" declaration. Verified to bite: an injected
colliding row fails all three tests by name.

Two known constraints, disclosed for the future decode stage (both
pre-existing, neither introduced or resolved here; the row's wording reflects
them):

1. The mandatory stamp is not consulted on the routed-expert load paths — the
   format's entire target population — which pass stamped_name=NULL
   (c/colibri.c:2217/2386/2580). Stamp-gated dispatch must be wired ahead of
   byte-arithmetic inference when the decode stage lands, exactly as
   docs/int4-rans256-g0.md's "THE STAMP IS MANDATORY" section warns.
2. ST_FMT_STAMP_MAX (4096, per this doc's own scan-bound section) is sized
   for hundreds of stamped tensors; a full-corpus routed-expert repack needs
   tens of thousands of stamp entries. The decode-stage PR must raise the
   bound or restructure the map before full-corpus repacks are loadable.

Shared-namespace scan (per this registry's convention): dev HEAD 7fb1159
has no rans row and no fmt=9 claim; all 51 open PRs enumerated 2026-08-04 —
none touch docs/FORMATS.md, claim a format ordinal, or use rans naming.

Requirement	Decisive evidence
Every factual cell true at its stated anchor	Each carries a file:line citation at dev 7fb1159 — checkable in-tree
Ordinal-less rows now inside the parity net	Injected colliding row → 3 named test failures; real doc → 5/5 green
Nothing else regresses	make check green: C battery 0 failures, Python 304 tests OK

Verification detail

• Cross-doc consistency: docs/int4-rans256-g0.md's registry stub updated in
  the same PR to match the landed row (it previously said ordinal
  (maintainer-assigned), status "proposed").
• Table structure: all rows column-count-consistent in both edited docs.
• The parity suite's plausibility floor now counts both row populations, so a
  parser drift that loses ordinal-less rows fails loudly rather than
  silently shrinking coverage.
• Independent blind fact-check re-derived every row cell against
  git show 7fb1159:<file> with zero discrepancies before this was opened.