Chunk records: the stride table, and the exception pinned by name

Walked every chunk on all 27 levels, grouped by six-byte header signature:

    1,506 chunks, 34,415 records, 74 distinct signatures
    55 distinct strides, 52..640, every one a multiple of 4
    73 of 74 signatures use exactly one stride

The exception is asserted rather than skipped, because "every type is uniform"
is precisely the claim that quietly stops being true:

    [75 42 ef f2 71 b5]   strides {76, 92, 104}

That is the variable-length type the module docs had referred to indirectly. It
is now pinned by signature and to those three strides exactly.

The 4-byte alignment is a result, not an artefact. A stride recovered from one
chunk's first-to-second record delta can inherit alignment from where that chunk
happened to sit; collecting all 55 strides across every type and requiring all
of them to be divisible by 4 rules that out, because a single off-by-one in one
signature would show. Asserted in
chunk_record_stride_is_four_byte_aligned_and_uniform_per_signature.

What this settles is the shape the decoder must handle: uniform stride per type,
4-byte aligned, one named exception. Field offsets within a record are now the
same for every record of a type, which is what makes per-type decoding
tractable. The fields themselves are still unnamed.

A layout that did NOT generalise, recorded so it is not rediscovered:

signature [53 c4 6c d7 9a 43], stride 108, 810 records, 63 of 108 byte positions
constant -- 48 bytes varying, then 60 bytes that are zero in every record, then a
constant 0x00010000. That reads like an inline buffer this type never uses, and
would have made a tidy field story. Requiring `stride == live span + zero run`
across every type with 50+ records per chunk gives 0 of 9. The zero tail belongs
to that one type and means nothing general.

Third occurrence of one editing mistake, and it is worth naming as a habit
rather than an accident: inserting a test before an existing one strands that
test's #[test] attribute on the new doc comment and silently unregisters it.
It has now happened three times, each time surfacing only as clippy's "never
used" and never as a missing test. Fixed by appending new tests at the end of
the file instead of anchoring them to an existing function, and verified by
listing registered tests rather than trusting a count.

241 tests, clippy clean, all five recent tests confirmed registered.

docs/roadmap.md

@@ -465,7 +465,13 @@ Phase 1 hands over the extents; this phase works out what each one contains.
       fixed within **all 71 types**, values `{1, 2, 4, 6, 8, 10}`. Disproved
       readings: an entry count (57 distinct fractional "sizes") and a
       distinct-leading-byte count (0 of 1,506 agree).
-- [ ] The chunk **record fields are not decoded**, and no type is named. The body
+- [~] The chunk **record fields are not decoded**, and no type is named -- but the
+      stride table is now measured: **74 signatures, 55 distinct strides, 52..640,
+      every stride a multiple of 4**, and 73 of 74 signatures use a single stride.
+      The exception is pinned: `[75 42 ef f2 71 b5]` at strides `{76, 92, 104}`.
+      Asserted including the exception, so "every type is uniform" cannot rot.
+      A per-type layout found for one type (48 bytes of data then 60 permanently
+      zero) does **not** generalise -- 0 of 9 types fit that shape. The body
       is dense (74% of `f32` reads plausible against a 49% random control) with
       an index-like tail -- 12 of 163 `u16` slots in the largest type stay below
       `0x1000` -- but **no count field** exists in the first 64 body bytes at any