The shortlist points at VU microcode; the decomp extents are unverified

391 candidates on correct bytes, 73 under 16 immediates. The densest, 0x2dca20,
164 bytes with three distinct immediates, disassembles through tools/overlay-anchors
as:

    xori.b $w0, $w0, 0xa2
    ext    $v0, $s0, 0, 1
    addu   $a2, $v0, $a2

xori.b and ext are VU1 mnemonics and three-operand addu is not MIPS32. Capstone is
decoding COP2: 0x2dca20 is VU microcode. Same answer 0x2ee138 gave.

That calls the frequency result into question more seriously than the displacement
did. The measurement filtered on opcodes excluding COP2, so VU cannot explain the
391 counts directly -- but the function extents come from the decomp's CPU
analysis, and if an extent spans a VU region the window scanned is mixed and the
immediate set attributed to that function is not a function's.

Status: the enrichment is real as a measurement of those windows; what the windows
are is now doubtful.

Next: verify decomp extents land on CPU code before trusting any of them -- decode
a sample and require a plausible prologue. Same shape as the cd16485 check, and the
fourth time a 'real shortlist' has needed one more verification first.

286 passing with the disc present, clippy clean.

docs/plan/level-assets.md

@@ -2541,3 +2541,50 @@ and reported every one with the same confidence as the kind that does.
 are a legitimate shortlist -- but the disassembly that would consume them must go
 through `tools/overlay-anchors`, whose output has now been checked against a word
 the build pins.
+
+### The shortlist points at VU microcode, not CPU code
+
+391 candidates on correct bytes, 73 with fewer than 16 immediates. The densest is
+`0x2dca20` -- 164 bytes, **three** distinct immediates, one of which is `0xc0`.
+
+Disassembled through `tools/overlay-anchors`:
+
+    0x2dca20: bnel   $a1, $fp, 0x2dca38
+    0x2dca24: lbu    $a2, ($s7)
+    0x2dca28: xori.b $w0, $w0, 0xa2          <-- VU
+    0x2dca2c: ext    $v0, $s0, 0, 1          <-- VU
+    0x2dca30: b      0x2dcac8
+    0x2dca38: sll    $a1, $a1, 4
+    0x2dca40: .word  0x0200202d
+    0x2dca48: addu   $a2, $v0, $a2          <-- 3-operand: MIPS-III, not MIPS32
+
+`xori.b` and `ext` are VU1 mnemonics and the three-operand `addu` is not MIPS32 at
+all. **Capstone is decoding COP2.** So `0x2dca20` is VU microcode, not a CPU
+function.
+
+That is the same answer `0x2ee138` gave. Two of the densest candidates in the
+"moby_classes offset" shortlist are vector-unit code.
+
+**This calls the frequency result into question again, and more seriously than
+the displacement did.** The enrichment measured 391 CPU functions carrying
+immediate `0x00c0` at 11x-45x over neighbours, and that measurement filtered on
+opcodes 0x09/0x0d/0x0f/0x0c/0x05/0x06 -- which **excludes COP2**. So VU code
+cannot explain those counts directly. But the *function extents* come from the
+decomp's CPU analysis, and if any extent spans a VU region then the window being
+scanned is mixed, and the immediate set attributed to that "function" is not a
+function's.
+
+**Honest status:** the enrichment is real as a measurement of those windows. What
+those windows are is now doubtful, because the decomp's extents have not been
+verified to land on CPU code, and two independent spot-checks of the densest
+candidates landed in VU microcode.
+
+**What this needs before it can be used:** verify that a known CPU function's decomp
+extent actually contains CPU instructions -- same shape as the `cd16485` check.
+Decode a handful of extents and require them to begin with a plausible prologue
+(`addiu $sp, $sp, -N` or `lui $gp`). Any extent that does not is a mis-bound or
+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.