Transcribe the 256-byte MobyInstance; oClass closes the instance-to-routine loop

The decomp carries an authentic MobyInstance layout of 0x100 bytes with every
field named. It is now in gc_formats::moby with a 67-entry offset map, attributed
as a transcription rather than presented as our own finding.

Two fields matter:

    0x40  animSeq      animation sequence pointer
    0x44  animSeqT     animation time parameter
    0x48  animSpeed    playback speed
    0x50  animLayers   animation layer list
    0x57  jointCnt     joint count -- non-zero means the moby is skinned
    0x58  jointCache   joint matrix cache
    0xBC  oClass       object class id -- the dispatch key

OCLASS CLOSES A LOOP THAT HAS BEEN OPEN FOR SEVERAL COMMITS. It is the field the
runtime uses to reach the lvl.vtbl handler tables, so an instance and its routine
are now linked by a named offset, rather than by an assumption about which axis
the two tables share. That assumption -- the positional correspondence -- is still
refuted, and still does not need to be true.

jointCnt and jointCache settle something from earlier in this log BY CONTRADICTION
rather than confirmation. A tie vertex's i16[3] was tested as a skin/joint index
and disproved: vertices sharing it were 0.95x FARTHER apart than vertices differing
in it. That stands and is unaffected -- this is the moby struct, and a moby is a
different object from a tie. Recording the distinction rather than letting "joints"
appear in two places look like a confirmation of the earlier hypothesis.

WHAT THIS DOES NOT DO IS FIND moby_anim. It names the instance-side state, so the
asset to locate is whatever those pointers reference, and we still do not know
where that is. The item's unblock condition is now sharper -- it needs the data
behind those pointers, not the struct.

PROVENANCE, AND WHAT THE TEST CAN ACTUALLY CHECK

This is not verified against disc data and cannot be: moby instances are runtime
objects and nothing of that shape is in the container. The test asserts what can be
asserted without the bytes -- offsets ascend, do not overlap, the last field lands
exactly on 0x100, and o_class sits at 0xBC immediately before triggers.

Worth keeping distinct from the collision finding. That project's FUNCTION ADDRESSES
did not transfer: they landed in NOBITS memory. A struct's field order is a
different kind of claim from an address in a program's layout, so one failing does
not impeach the other -- but the distinction is real, and PROVENANCE.md now records
which is which rather than citing the project as a single authority.

268 tests.

docs/roadmap.md

@@ -427,6 +427,15 @@ Phase 1 hands over the extents; this phase works out what each one contains.
       level instantiates -- and the space is shared rather than renumbered
       (1,163 distinct out of 5,878 records; level 0 supplies 20%, not a
       majority). A class can now be recognised across levels by id. Asserted.
+- [x] The **moby instance is named**: `MobyInstance`, 256 bytes, 67 fields,
+      transcribed from the decomp's `include/structs.h` into `gc_formats::moby`
+      with an offset map. `oClass` at `0xBC` is the dispatch key into `lvl.vtbl`,
+      which closes the instance-to-routine link; `animSeq`/`animLayers`/
+      `jointCnt`/`jointCache` at `0x40..0x5C` name the instance-side animation
+      state. **Not verified against disc bytes** -- mobies are runtime objects and
+      nothing of that shape is in the container; the test asserts what can be
+      asserted without them (offsets ascend, do not overlap, land exactly on
+      0x100). Layout claim from a third party, attributed as such.
 - [ ] `moby_anim` — **still open, and the obvious reading is ruled out.** An
       instance table would have to scale with the level's moby class count, but
       **per-chunk-type record counts are level-independent** -- the same types