Find moby class references in chunk records at 38x chance

Range measured: level 0, the 900000 bytes before the trailer; 28 chunks, 475
records, 67780 u16 slots. Reference set: the 238 distinct o_class values from
level 0's moby class table, read through LevelCoreHeader.

Method: scan every u16 in every record, count membership in the moby class set,
and compare against the chance rate of 238/65536 per slot.

Result: 9493 hits against 246.1 expected, a 38.6x excess.

The hits are concentrated, not spread. Slots 129 through 140 -- twelve
consecutive u16, bytes 258 to 280 of the record -- carry 105 to 188 hits each.
Nothing else comes close except a separate cluster at slot 38. Every chunk
contributes in proportion to its record count.

A contiguous twelve-value array that is mostly moby class identifiers is what a
model or instance definition listing referenced mobies would look like.

Enrichment is not identification. A 38x excess over chance is strong evidence
these are moby class IDs rather than incidental small integers, but it does not
establish that the chunk is moby_anim: an instance table, a model list and an
animation table would all reference class IDs. The format and the meaning of
slots 129-140 are both still unnamed.

Also unverified: whether the twelve slots are always the same fields. The
offsets come from the largest records, and this scan pooled all chunk types
together, so a type with a different stride could place them elsewhere.

Process note: the first version of this test extracted the moby class table by
hand and got 67 entries instead of 238, which made every chunk look like a hit
and would have supported any conclusion. Reading it through LevelCoreHeader was
what made the measurement meaningful.

docs/formats/core-data-regions.md

@@ -874,3 +874,45 @@ correlating.
 
 **Still open:** what the 64 types mean, which record fields are
 index/length/offset, and whether any type is moby_anim.
+
+## Chunk records reference moby class IDs at 38x chance
+
+**Range measured:** level 0, the 900,000 bytes before the trailer; 28 chunks,
+475 records, 67,780 `u16` slots. Reference set: the 238 distinct `o_class`
+values from level 0's moby class table, read through `LevelCoreHeader`.
+
+**Method:** scan every `u16` in every record; count how many are in the moby
+class set. Compare against the rate expected if hits were chance, at
+238/65536 per slot.
+
+**Result: 9,493 hits against 246.1 expected -- 38.6x excess.**
+
+The hits are not spread. They concentrate in a contiguous run of `u16` slots:
+
+| slot | hits | | slot | hits |
+|---|---|---|---|---|
+| 138 | 188 | | 134 | 173 |
+| 135 | 182 | | 136 | 168 |
+| 137 | 180 | | 129 | 139 |
+| | | | 130 | 131 |
+
+Slots 129 through 140 -- twelve consecutive `u16`, that is bytes 258 through
+280 of the record -- carry 105 to 188 hits each, and nothing else in the record
+comes close except a separate cluster at slot 38.
+
+**What this looks like.** A contiguous twelve-value array in which most entries
+are moby class identifiers is what a model or instance definition listing the
+mobies it references would look like. Every chunk contributes in proportion to
+its record count: the stride-340 chunk with 77 records has 1,451 hits, the
+stride-368 chunk 1,384, the stride-148 chunk with 10 records has 254.
+
+**What this does not show.** Enrichment is not identification. A 38x excess
+over chance is strong evidence that these values are moby class IDs rather
+than incidental small integers, but it does not establish that the containing
+chunk is `moby_anim` -- an instance table, a model list and an animation table
+would all reference class IDs. The format is still unnamed, and so is the
+meaning of slots 129-140.
+
+**Also unverified:** whether the twelve slots are always the same fields. The
+offsets are quoted from the largest records; a chunk type with a different
+stride would place them elsewhere, and this scan pooled all types together.