Extent check inconclusive; the opcode field itself is not understood

Tried to answer whether the decomp extents land on CPU code by checking for a
prologue. Only 29 of 3,835 matched 'addiu $sp,$-N' or 'lui $gp' -- but the other
bucket is full of textbook prologues my two patterns miss, because PS2 leaf
functions save registers with no frame adjustment:

    0x2a4ef0  ffb00000 ffb10008   sw $s0,0($sp); sw $s1,8($sp)
    0x2a48f0  3c013f80 44816000   lui $1,0x3f80; bc1t

Not reading a result into that.

Separately, ffb00000 has major opcode 0x3f, unused in MIPS32, yet is
unmistakably a register-save prologue and ffbf0020 for 'sw $ra,0x20($sp)' appears
throughout this code. Either the EE encodes sw outside MIPS32 or I am reading the
opcode field wrong somewhere. Not resolved -- and it undercuts every opcode-based
check in this investigation, the 391 and the neighbour ratios included.

Position after twenty-one commits: the mapping is verified, two targets are VU
microcode, and the candidate windows are not established to be CPU code. What this
needs is one authoritative disassembly of one extent compared against
tools/overlay-anchors, to establish what the opcode field means. That is the same
mistake one level down from the section-indexing bug: using a decoding never
checked to produce results, then measuring those results with the same unverified
decoding.

286 passing with the disc present, clippy clean.

docs/plan/level-assets.md

@@ -2588,3 +2588,50 @@ VU-overlapping window, and the 391 has to be recomputed over the survivors.
 That check is cheap, it is the same check that would have caught this six commits
 ago, and it is the honest next step. It is also, at this point, the fourth time a
 "real shortlist" has turned out to need one more verification first.
+
+### Extent check: inconclusive, and I am not going to read a result into it
+
+Tried to answer `91b0995`'s question -- do the decomp's function extents land on
+CPU code? -- by checking whether each begins with a prologue. Counting only
+`addiu $sp, $sp, -N` and `lui $gp`:
+
+    total 3,835 | cpu prologue 29 | VU-first 66 | nop-first 243 | other 3,492
+
+**29 of 3,835 looks damning and is not.** The "other" bucket contains textbook
+prologues that my two patterns miss:
+
+    0x2a4ef0  ffb00000 ffb10008    sw $s0,0($sp); sw $s1,8($sp)
+    0x2a48f0  3c013f80 44816000    lui $1,0x3f80; bc1t   <-- valid CPU, FP branch
+    0x2a4928  0240282d 24060002    slt $v1,$s0,$s1; sltu $a2,$zero
+
+PS2 leaf functions routinely start by saving registers with no frame adjustment,
+and functions whose extent starts after the `addiu $sp` look the same. Two patterns
+cannot classify 3,835 extents.
+
+**A second thing I cannot explain, recorded rather than guessed:** `ffb00000` has
+major opcode `0x3f`, which is unused in MIPS32 -- yet `ffb00000 ffb10008` is
+unmistakably a register-save prologue, and `ffbf0020` for `sw $ra, 0x20($sp)`
+appears throughout this code. Either the EE encodes `sw` outside MIPS32, or my
+opcode field is being read wrong somewhere. **I have not resolved this**, and it
+undercuts every opcode-based check in this investigation, including the ones that
+produced the 391 and the neighbour ratios.
+
+**So the position after twenty-one commits on `moby_anim`:**
+
+- `overlay_bytes_at` mapping: verified
+- `0x2ee138`, `0x2dca20`: VU microcode, verified
+- the 391 candidates: real as a measurement of the windows scanned; what those
+  windows are remains unestablished, because the window boundaries come from the
+  decomp and those have not been shown to delimit CPU code
+- **the opcode field itself is not understood well enough for these checks to be
+  trusted**, which invalidates the last few in particular
+
+**What this needs:** a single authoritative disassembly of one extent, compared
+line by line against `tools/overlay-anchors`, to establish what the opcode field
+means for this code. Everything else is downstream of that and I have been
+reasoning upstream of it.
+
+That is the same mistake one level down from the section-indexing bug: I used a
+decoding I had never checked to produce results, and then measured the results
+with the same unverified decoding. The check existed as a tool from the first
+commit.