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/formats/core-data-regions.md

@@ -2288,3 +2288,51 @@ What would settle it, and none of these are cheap:
     through its dispatch records. If an id in the candidate resolved to a class
     whose name is a volume trigger, that would be decisive. No class name
     containing "volume" exists on the disc, which is why this is not available.
+
+## Chunk records: what the stride table settles, and one signature it does not
+
+Walked every chunk on all 27 levels and grouped by its six-byte header signature:
+
+    1,506 chunks, 34,415 records, 74 distinct signatures
+    55 distinct strides, from 52 to 640
+    every one of those 55 strides is a multiple of 4
+    73 of 74 signatures use exactly ONE stride
+
+**The single exception**, asserted rather than skipped so that "every type is
+uniform" cannot quietly stop being true:
+
+    signature [75, 42, ef, f2, 71, b5]   strides {76, 92, 104}
+
+This is the variable-length type the module documentation already referred to
+indirectly. It is now named by its signature and pinned to those three strides
+exactly. Everything else is a fixed-stride array, which is the structural fact
+that makes per-type field decoding tractable at all: a record's field offsets are
+the same for every record of its type.
+
+The 4-byte alignment is a real result rather than an artefact of how the stride
+was inferred. A stride recovered from one chunk's first-to-second record delta
+could inherit alignment from where that chunk happened to sit; collecting all 55
+distinct strides across every type and requiring all of them to be divisible by
+4 rules that out, because an off-by-one in one signature would show up.
+
+### A record layout that did not generalise
+
+One type looked like a clean find. Signature `[53, c4, 6c, d7, 9a, 43]`, stride
+108, 810 records, 63 of 108 byte positions constant:
+
+    +0x00 .. +0x30   48 bytes varying per record
+    +0x30 .. +0x6c   60 bytes that are ZERO in every record
+    +0x68            0x00010000, constant
+
+A fixed data block followed by a permanently empty region reads like an inline
+buffer that this type never uses, and that would have been a tidy field story.
+
+It does not generalise. Requiring a contiguous always-zero run and checking
+`stride == live span + zero run` across every type with 50+ records per chunk
+gave **0 of 9**. The zero tail belongs to that one type and means nothing
+general. Recorded because "48 bytes then 60 dead bytes" is specific enough to
+look like a layout and would otherwise be rediscovered and over-read.
+
+Neither of these decodes any record's *fields*. What is now settled is the
+shape the decoder has to handle: uniform stride per type, 4-byte aligned, with
+one named exception carrying three strides.