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.
ReaperOfVeriod
b13901a7e7