Correct the moby class array offset: it is per chunk type

The previous commit reported moby class IDs at u16 slots 129 through 140. That
was a pooling artifact. Repeating the scan per chunk type shows every type
places its class array at a different offset:

  aac4  129-134     82c4  104-109     4ec4  106-111
  b8c4  120-125     9943   82-87      79c4  111-115
  3245   24-29      and so on across all 26 types

Slots 129-140 were simply the type with the largest stride dominating a scan
that pooled every type together. The previous commit flagged this as
unverified; the check confirmed the flag.

What survives is stronger than what it replaced. In every one of the 26 types
the top hits form a contiguous run of consecutive u16 slots. The real
invariant is therefore per-type: each chunk type has its own class array, at
its own offset, of its own length. That fits the header-implies-one-stride
result -- each type is a distinct record layout -- but the class array is a
per-type field, not a common one at a fixed offset.

The moby reference itself is unaffected. The 38.6x excess was measured across
all records and does not depend on which slots were counted.

docs/formats/core-data-regions.md

@@ -913,6 +913,36 @@ 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.
+**Correction to the above: the slot offsets were a pooling artifact.**
+
+The entry above reported slots 129 through 140. Repeating the scan per chunk
+type shows that is wrong: **every chunk type places its class array at a
+different offset.**
+
+| type (header prefix) | top hit slots |
+|---|---|
+| `aac4` | 129-134 |
+| `82c4` | 104-109 |
+| `4ec4` | 106-111 |
+| `b8c4` | 120-125 |
+| `9943` | 82-87 |
+| `79c4` | 111-115 |
+| `3245` | 24-29 |
+
+Slots 129-140 were simply the type with the largest stride, dominating a scan
+that pooled all types together. The previous entry flagged exactly this as
+unverified, and the check confirmed the flag.
+
+**What survives the correction.** In every one of the 26 types the top hits
+form a **contiguous run of consecutive `u16` slots**. That is the real
+invariant, and it is per-type: each chunk type has its own class array at its
+own offset, of its own length.
+
+So the corrected statement is: chunk records contain a contiguous array of
+moby class IDs, and where that array sits depends on the chunk's type header.
+This is consistent with each type being a distinct record layout, which is
+what the header-implies-one-stride result already indicated -- but the class
+array is a per-type field, not a common one at a fixed offset.
+
+The moby reference itself is unaffected: 38.6x excess measured across all
+records stands, since it does not depend on which slots were counted.