Identify the chunk header as a type ID that determines the record stride

Range measured: all 27 levels, 1123 chunks.

Method: group chunks by their 16-byte header; for each distinct header,
collect the set of strides seen across every level it appears on.

Result: only 64 distinct headers across 1123 chunks. The header is a type
identifier, not a per-chunk descriptor -- the same 16 bytes recur on every
level. And 63 of those 64 imply exactly one stride, so header to record layout
is very nearly a function.

The exception is header 7542eff271b522a79e45348cca4509ff, seen with strides 76,
92 and 104. Either three types share a header or one is a misparse.

This also settles the previous entry's open question about D/E/F being
incidental. Grouping by header bytes 9 and 13:

  DE   26 chunks,   2 strides (184, 344)
  EE 1050 chunks,  46 strides
  EF   34 chunks,   2 strides (268, 640)
  FF   13 chunks,   1 stride  (520)

Rare tags are tightly coupled to their layouts -- FF is a single stride across
all 13 chunks -- while EE is heterogeneous. That is what a type tag looks
like.

Consequence: a chunk can be dispatched on its header to a record layout, and
63 of 64 headers give that layout's size without inspecting a record. First
point in this container where a field does real work rather than correlating.

Still open: what the 64 types mean, which record fields are
index/length/offset, and whether any type is moby_anim.

docs/formats/core-data-regions.md

@@ -832,3 +832,45 @@ so the ASCII in bytes 9 and 13 could be incidental.
 tags, which record fields are index/length/offset, and whether a chunk is
 moby_anim. The `D`/`E`/`F` values are suggestive enough to be worth testing
 against a known type table, but that has not been done.
+
+## The header is a type ID, and the type determines the stride
+
+**Range measured:** all 27 levels, 1,123 chunks.
+
+**Method:** group chunks by their 16-byte header; for each distinct header,
+collect the set of strides observed across every level it appears on.
+
+**Result: only 64 distinct headers across 1,123 chunks.** The header is a
+type identifier, not a per-chunk descriptor -- the same 16 bytes recur on
+every level.
+
+**63 of the 64 headers imply exactly one stride.** So header to record layout
+is very nearly a function: the type determines the record size.
+
+The single exception is header `7542eff271b522a79e45348cca4509ff`, which
+appears with three strides, 76, 92 and 104. Either three types share a header,
+or one of the three is a misparse. Not resolved.
+
+**The ASCII reading is confirmed as a type tag.** Grouping by header bytes 9
+and 13:
+
+| tag | chunks | distinct strides |
+|---|---|---|
+| `DE` | 26 | 2 (184, 344) |
+| `EE` | 1050 | 46 |
+| `EF` | 34 | 2 (268, 640) |
+| `FF` | 13 | 1 (520) |
+
+The rare tags are tightly coupled to their layouts -- `FF` is a single stride
+across all 13 of its chunks -- while `EE` is heterogeneous with 46. That
+pattern is what a type tag should look like, and it settles the earlier
+suggestion that the D/E/F bytes were incidental: they are not.
+
+**What this is good for.** A chunk can now be dispatched on its header to a
+record layout, and 63 of 64 headers determine that layout's size without
+inspecting any record. That is a usable parse entry point, and it is the first
+point in this container where a field is doing real work rather than merely
+correlating.
+
+**Still open:** what the 64 types mean, which record fields are
+index/length/offset, and whether any type is moby_anim.