d97e7df was wrong: my section offset was wrong, not the decoder

Ran gc-overlay-anchors on 0x2ee138 as d97e7df directed. It reports 6 of 12 words
did not decode -- but the words disagree:

    tool:    0x2ee138  0x4bc00083
    my read: 0x2ee138  0xd8a10000

Different bytes at the same address. My offset into the section is wrong, so the
'opcode 0x36 is invalid' finding was about bytes never at that address. That
invalidates d97e7df's conclusion and its 'second decode error' framing: the
decoder was never the problem.

The tool's words are COP2 (0x12), VU1 vector-unit instructions, which capstone
will not render under plain MIPS32. So its 'did not decode' is expected for VU
code and says nothing either.

Four bugs in this investigation, all mine: un-masked branch target, transposed
address, invalid opcode read from wrong bytes, and the offset mapping itself.

Every one was a self-consistent probe reporting a clean number. The check that
catches all four is verifying the tool against a known-correct case before using
it to generate a finding -- which d97e7df recommended and I then skipped.

Nothing about 0x2ee138 is now known: not VU code, not data, not a function. The
address is the correctly decoded jal target; what is there is unestablished.

Next step is to fix and verify the address-to-overlay mapping before re-reading
anything. Until then no address computed by hand in this investigation is
trustworthy, including the 0x3a8060 walk that happened to decode.

284 passing with the disc present, clippy clean.

docs/plan/level-assets.md

@@ -2356,3 +2356,47 @@ The chain as far as it is established, with nothing inferred beyond it:
 
 Everything above that is verified; what `0x2ee138` returns is **unknown**, and it
 is the single remaining link between the program and `moby_classes.offset`.
+
+### d97e7df's conclusion was wrong: my section offset was wrong, not the bytes
+
+Ran `tools/overlay-anchors --disasm` on `0x2ee138` as `d97e7df` said to. It
+reports "6 of 12 words did not decode" -- but compare the *words*:
+
+    tool:    0x2ee138  0x4bc00083
+    my read: 0x2ee138  0xd8a10000
+
+Different bytes at the same address. **My offset into the section is wrong**, so
+the "opcode 0x36 is not a valid MIPS opcode" finding was about bytes that were
+never at that address. That invalidates the conclusion in `d97e7df` as well as the
+"second decode error" framing in it -- the decoder was never the problem.
+
+The tool's words are `0x4bc00083` and friends, which are **COP2** (opcode 0x12),
+i.e. VU1 vector-unit instructions, which capstone will not render under a plain
+MIPS32 configuration. So capstone's "did not decode" is expected for VU code and
+carries no information either.
+
+Four separate bugs in this one investigation now, all mine:
+
+1. un-masked J-type branch target -> false negative on callers
+2. transposed hex address -> disassembled the wrong place
+3. concluded "invalid opcode" from bytes that were not at that address
+4. the section-offset mapping itself is wrong
+
+**The one lesson, and it is the same one four times over:** every one of these was
+a self-consistent probe reporting a clean number. The discipline that would have
+caught all four is the one `d97e7df` recommended and I then skipped -- verify the
+tool against a known-correct case *before* using it to generate a finding. The
+known-correct case was sitting in the decomp's own extents, and I used my own
+arithmetic instead.
+
+**Nothing about `0x2ee138` is now known.** Not that it is VU code, not that it is
+data, not that it is a function. The address `0x2ee138` is the correctly decoded
+`jal` target from `0x3a3d70`; what is at that address is unestablished.
+
+The correct next step is to fix the address-to-overlay mapping in `gc-formats`
+(`OverlaySection` gives `dest` and `data`, and the mapping between them is what
+has been wrong all along), verify it against a section whose contents are
+independently known, and only then re-read `0x2ee138`. Until that mapping is
+verified, **no address in this investigation that I computed by hand is
+trustworthy** -- including the `0x3a8060` walk, which happened to decode but may
+have been read from the wrong bytes.