Redone on correct bytes: the disassembly chain is gone, 0x2ee138 is VU microcode

Re-read through overlay_bytes_at, the verified flat mapping from cd16485.

0x2ee138 is VU1 microcode: five COP2 instructions and a jr $ra stub. Nothing you
jal into, so the jal read from 0x3a3d70 cannot be right either -- and that
instruction was itself read from displaced bytes and must be re-read.

0x3a8060 is not what cee17c9 said. On correct bytes there is no addiu r17, r18,
0xc0, no 16-byte-stride walk and no function prologue; the first word is opcode
0x1f, which is not a MIPS user opcode. cee17c9's central finding does not exist.

State: overlay_bytes_at verified; 0x2ee138 is VU microcode, verified; the 0x3a8060
walk retracted; the frequency and neighbour-enrichment numbers not re-measured and
not quotable as exact; the e1482ab jal chain unverified, built from displaced bytes
and pointing at now-known VU code.

What is left of moby_anim is nothing. No loader located, one frequency result to
redo from scratch on correct bytes, and no reason to expect it to survive.

285 passing with the disc present, clippy clean.

docs/plan/level-assets.md

@@ -2450,3 +2450,52 @@ remember.
 And then: **verify it**, the way the check above verifies, against a word the
 decomp already pins. I had that verification available from the first probe and
 skipped it sixteen times.
+
+### Redone on correct bytes: the disassembly chain is gone
+
+Re-read through `overlay_bytes_at` (the verified flat mapping from `cd16485`).
+
+**`0x2ee138` is VU1 microcode**, not a function:
+
+    0x2ee138  4bc00083  COP2
+    0x2ee13c  4bc1086a  COP2
+    0x2ee140  4b01083d  COP2
+    0x2ee144  4b01104a  COP2
+    0x2ee148  48240800  COP2
+    0x2ee14c  03e00008  jr $ra
+
+Five COP2 vector-unit instructions and a return stub. Nothing you `jal` into. So
+the `jal 0x2ee138` read from `0x3a3d70` cannot be right either -- and that
+instruction was itself read from displaced bytes, so it must be re-read before
+anything is concluded about it.
+
+**`0x3a8060` is not what `cee17c9` said.** On correct bytes:
+
+    0x3a8060  7c820000  (opcode 0x1f -- not a MIPS user opcode)
+    0x3a8064  0080182d  SPECIAL0
+    0x3a8068  3c020019  lui
+    0x3a8070  8c47c0b0  lw r2, 0xc0b0(r7)
+    0x3a807c  0c0b792c  jal
+
+**There is no `addiu r17, r18, 0xc0`, no 16-byte-stride walk, and no function
+prologue.** `cee17c9`'s central finding does not exist. The "it is an address, not
+a float" conclusion was about bytes that were never at that address.
+
+**State of the investigation, honestly:**
+
+| result | status |
+|---|---|
+| `overlay_bytes_at` mapping | **verified** (`cd16485`) |
+| `0x2ee138` is VU1 microcode | verified just now, on correct bytes |
+| `0x3a8060` walk, 16-byte stride, address-not-float | **retracted** |
+| immediate frequency / neighbour enrichment | **not re-measured**; uniformly displaced, ratios plausibly robust, exact counts not |
+| the `jal` chain from `e1482ab` | **unverified** -- built from displaced bytes, and one target is now known to be VU code |
+
+**What is left of `moby_anim`:** nothing. Every disassembly-derived result is
+gone, the one frequency result needs re-measuring from scratch on correct bytes,
+and no loader has been located.
+
+The honest next step is to redo the frequency measurement with `overlay_bytes_at`
+and the decomp extents, and to accept that it may well produce nothing -- the
+`0xc0` enrichment was a property of displaced windows, and there is no reason to
+expect it to survive.