Attempt the moby_anim unblock: a location and a failure, not a result

Asked whether the blocked items could be unblocked, and tried the one that looked
tractable. It did not work, and this records where and why rather than leaving the
attempt implicit.

VERDICT PER ITEM

  moby_anim    probably -- disc-side work. TRIED, stalled, see below
  tfrag morph  maybe -- would need the engine's own morph code
  volumes      no -- needs a count of level 0's trigger volumes from a map
  collision    no -- needs a debug build or an external format description

THE ATTEMPT

MobyInstance names animSeq, animLayers, jointCnt and jointCache. Those are RAM
pointers and useless on the disc, so the search moved to what they point AT,
reached from the moby class blob.

Level 0, 187 moby classes. The span opens with the part-table offset: 0x80 on 69
classes, 0x90 on 34, ranging 0 to 229,184 across the rest. So each class carries
roughly a 0x40-byte header before its parts, and that header is unexplored.

Per byte over +0x00..+0x40, how many of the 187 classes are non-zero:

    +0x00  177   the part-table offset
    +0x07  185   8 distinct values, 1..3
    +0x26  181   100 distinct -- varies per class
    +0x27  187   8 distinct
    +0x2d  187   8 distinct
    +0x30  170   120 distinct
    +0x3c  184   120 distinct
    +0x3e  187   110 distinct

Six or seven fields are constant across every class and about a dozen vary. None
is identifiable. The obvious discriminator -- find the field that points OUTSIDE
the span -- does not resolve, because every varying field holds values in the tens
of thousands, the same order as the span offsets themselves. They may be
intra-span pointers or they may be sizes, and nothing here separates them.

WHERE IT STALLS

Distinguishing them needs one of: the class loader in the overlay's .text, which
is now readable with the fixed disassembler, or a class whose animation is known
from outside the disc. Neither has been done, and the first is the obvious next
step rather than a dead end.

So moby_anim is NOT unblocked. What the attempt does establish is a location, a
field count to classify, and a specific reason the easy discriminator fails --
which is more than the item had, and considerably more than "still open".

The other three are unchanged and I do not think they are reachable from here.
Collision needs the assert, which is unreferenced in retail, or an external
description of R&C2's collision cell. Volumes needs ground truth nobody in this
repo can supply. Both are written up with those conditions attached.

docs/roadmap.md

@@ -439,7 +439,16 @@ Phase 1 hands over the extents; this phase works out what each one contains.
       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
+- [ ] `moby_anim` — **unblock attempted and not achieved.** The unblock was "the
+      data behind those pointers", and the pointers are RAM addresses, so the
+      search moved to the moby class blob: 187 classes on level 0, part-table
+      offset `0x80` on 69 and `0x90` on 34, so each carries a `~0x40`-byte header
+      before its parts. That header has ~6 constant and ~12 per-class-varying
+      fields and **none is yet identifiable** — the varying ones hold values of
+      the same order as the span offsets, so the obvious discriminator ("the field
+      that points outside the span") does not resolve. Needs the class loader in
+      the overlay's `.text`, which is now readable, or a class whose animation is
+      known externally. Recorded as a stall with a location, not as progress. 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
       report 90, 77, 50 and 47 on every level tried, and the largest type