Resolve the colliding header: three types share 16 bytes

Header 7542eff271b522a79e45348cca4509ff was reported with three strides, 76, 92
and 104. It is not one type with a variable stride, and not a misparse.

It appears three times per level, always with record count 9, always in the
same order at the same offsets within the region:

  offset   stride  count  first  last
  863842      92      9     928  1640
  867554      76      9     912  1520
  872866     104      9    1000  1832

The offsets are 3712 apart each time and the strides differ, so these are three
separate chunks sharing 16 header bytes.

Consequence for the type ID: 64 distinct headers for 66 distinct record
layouts, not 64 for 64. The header is nearly a type ID but does not uniquely
determine the layout. Not excluded: a distinguishing byte sits outside the 16
captured, or the layout varies within a type.

This does not change "63 of 64 headers imply one stride", which remains true,
but the mapping is not a bijection and should not be used as one. Worth
checking before the parser is extended to dispatch on header alone.

docs/formats/core-data-regions.md

@@ -847,9 +847,33 @@ 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
+**Resolved: the single exception is three types sharing a header.**
-appears with three strides, 76, 92 and 104. Either three types share a header,
+
-or one of the three is a misparse. Not resolved.
+Header `7542eff271b522a79e45348cca4509ff` was reported with three strides, 76,
+92 and 104. It is not one type with a variable stride, and not a misparse.
+
+It appears **three times per level**, always with record count 9, always in the
+same order and always at the same offsets within the region. On level 0 and on
+every other level checked:
+
+| offset | stride | count | first offset | last offset |
+|---|---|---|---|---|
+| 863842 | 92 | 9 | 928 | 1640 |
+| 867554 | 76 | 9 | 912 | 1520 |
+| 872866 | 104 | 9 | 1000 | 1832 |
+
+The offsets are 3,712 apart each time and the strides differ, so these are
+three separate chunks that happen to share 16 header bytes.
+
+**Consequence for the type ID.** 64 distinct headers for 66 distinct
+record layouts, not 64 for 64. The header is *nearly* a type ID but does not
+uniquely determine the layout: whatever distinguishes these three is not in the
+16 bytes the header captures. Candidates not excluded: a distinguishing byte
+sits outside the 16 captured, or the layout varies within a type.
+
+This does not change the earlier conclusion that 63 of 64 headers imply one
+stride -- that remains 63 of 64 -- but the mapping is not a bijection and
+should not be used as one.
 
 **The ASCII reading is confirmed as a type tag.** Grouping by header bytes 9
 and 13: