Confirm chunk offsets address real records on all 27 levels

Range measured: each level's post-shrub region, 900000 bytes before the
constant trailer.

Method: per chunk, read tagged offsets as 0xF0000000 | low24, take stride as
the first delta, load one record per offset at chunk_start + low, and count
byte positions constant across that chunk's records.

Result: 1096 chunks and roughly 13000 records resolve on all 27 levels. Every
level shows 17-21% of byte positions constant across its own records. Level 0:
27 chunks, 466 records, 20.8% constant. The stride-368 chunk (77 records) has
26 constant positions of 368; the stride-340 chunk has 25 of 340. Constant
positions cluster at the record end -- 267-276 for stride 368, 258-268 for
stride 340 -- so a footer, not scattered padding.

The tag is uniform: every tagged offset has top byte 0xF0 on all levels.

This settles the previous entry's framing. Resolving at chunk_start + low
yields records with ~20% constant positions, which does not happen by chance,
so the offsets genuinely address records and those records share a layout.

Still not decoded: the 16-byte header, the 0xF0 tag, which fields are
index/length/offset, and whether a chunk is moby_anim. A parser can extract
chunks and records bounds-checked today; naming the fields needs a domain
argument this project has not found.

docs/formats/core-data-regions.md

@@ -764,3 +764,38 @@ both cases, which is the same mistake twice.
 **Not decoded.** What the 16-byte header is, what the `0xF` nibble tags, where
 the chunk data lives, and what the chunk *means* are all open. The container
 framing is established; its contents are not.
+
+## Chunk records resolve, and the layout is consistent across levels
+
+**Range measured:** each level's post-shrub region, taken as the 900,000 bytes
+before the constant trailer.
+
+**Method:** for each chunk, read the tagged offsets as `0xF0000000 | low24`,
+take the stride as the first delta, load one record per offset at
+`chunk_start + low`, and count byte positions that are constant across that
+chunk's records.
+
+**Result: 1,096 chunks and roughly 13,000 records resolve on all 27 levels.**
+Every level's chunks show 17-21% of byte positions constant across their own
+records — a consistent field layout rather than noise.
+
+Level 0 in detail: 27 chunks resolve, 466 records, 20.8% constant. The
+stride-368 chunk (77 records) has 26 constant positions out of 368; the
+stride-340 chunk (77 records) has 25 out of 340. Constant positions cluster
+near the record end — 267-276 and following for stride 368, 258-268 for stride
+340 — which is a footer or tail, not scattered padding.
+
+**The tag is uniform.** Every tagged offset seen has top byte `0xF0`, i.e.
+`0xF0000000 | low24`, on all levels.
+
+**What this settles.** The container framing from the previous entry is not a
+coincidence of byte patterns: the offsets genuinely address records, and those
+records share a field layout. The chunk-relative base is confirmed because
+resolving at `chunk_start + low` yields records with ~20% constant positions,
+which does not happen by chance.
+
+**Still not decoded.** The 16-byte header (opaque, per-chunk), the meaning of
+the `0xF0` tag, which fields are index/length/offset, and whether a chunk is
+moby_anim or something else. A parser can extract chunks and records
+bounds-checked today; naming fields needs a domain argument this project has
+not yet found.