Show the collision payload is verbatim in RAM, and retract the "not in RAM" claim

This overturns the premise collision work was blocked on.

Searching the level-0 savestate for a probe from collision payload +1024 hits at
0xac6c00; a probe from +64 hits at 0xac6840. The difference is 0x3C0 = 960, which
is exactly 1024 - 64, so the payload sits at a fixed relative address -- RAM
0xac6800 for the disc address 0x27e800 -- and reading it back is byte-for-byte the
disc's own bytes:

  RAM  0xac6800  0b 00 21 00 b6 08 ad 08 a4 08 6b 08 38 08 63 07
  disc 0x27e800  0b 00 21 00 b6 08 ad 08 a4 08 6b 08 38 08 63 07

Nothing is reshaped. That is the opposite of the tie block, where the loader
relocates a pointer inside each record.

The retraction. The previous note reads: "level 1's 24 x 16 grid dimensions
appear in memory, level 0's 11 x 33 appear nowhere, so disc-side decoding has to
work against the reshaped form." Level 0's dimensions ARE in RAM, at 0xac6800 --
0b 00 and 21 00 are the first two bytes of the block, 11 and 33. The search that
missed them looked for 0b 00 00 00 21 00 00 00, the dimensions as a pair of u32s.
They are stored as two u16s, so that pattern never occurs.

So the negative result was an artifact of the search pattern, not evidence about
the data -- and it was then used as a premise for several rounds of disc-side
work. Both lessons were already written down in AGENTS.md and both were re-learned:
a negative from a byte search bounds the search, not the format; and the control
here is one command -- read the predicted RAM address and compare it to the disc --
which would have shown the verbatim copy immediately.

Also recorded while mapping it: the payload contains ascending u32 offset tables
from +1024 onward, and its first two bytes are the grid dimensions, so level 0's
grid is 11 x 33.

The cell layout itself is still undecoded, but the blocker is gone: disc-side
decoding no longer has to work against a reshaped form.

docs/plan/pcsx2-verification.md

@@ -783,3 +783,43 @@ running game's own copy of one chunk.
 with 02 00]`. The `02 00` is unexplained -- it may be a record type or an
 alignment the loader needs -- but it is constant, so it carries no per-record
 information either.
+
+## The collision payload is verbatim in RAM -- and the earlier "not in RAM" was wrong
+
+**This overturns the premise the collision work was blocked on.**
+
+Searching the level-0 savestate for a probe from collision payload `+1024` hits at
+`0xac6c00`; a probe from `+64` hits at `0xac6840`. The difference is 0x3C0 = 960,
+which is exactly 1024 - 64. So the payload sits at a fixed relative address --
+RAM `0xac6800` for the payload whose disc address is `0x27e800` -- and reading
+that address back gives byte-for-byte the disc's own bytes:
+
+    RAM  0xac6800  0b 00 21 00 b6 08 ad 08 a4 08 6b 08 38 08 63 07
+    disc 0x27e800  0b 00 21 00 b6 08 ad 08 a4 08 6b 08 38 08 63 07
+
+**Nothing is reshaped.** That is the opposite of the tie block, where the loader
+relocates a pointer inside each record, and the opposite of what this file
+previously asserted for collision.
+
+### The correction
+
+The earlier note here reads: "level 1's `24 x 16` grid dimensions appear in
+memory, level 0's `11 x 33` appear nowhere, so disc-side decoding has to work
+against the reshaped form."
+
+**Level 0's dimensions are in RAM, at `0xac6800`** -- `0b 00` and `21 00` are the
+two leading bytes of the payload, 11 and 33.
+
+The search that missed them looked for the pattern `0b 00 00 00 21 00 00 00`,
+i.e. the two dimensions as a pair of `u32`s. They are stored as two `u16`s, so
+that pattern never occurs. The negative result was an artifact of the search
+pattern, not evidence about the data -- and it was then used as a premise for
+the next several rounds of disc-side work.
+
+Two lessons, both already written down and both re-learned:
+
+- **a negative result from a byte search bounds the search, not the format.**
+  Getting the pattern right is part of the measurement;
+- the control for this one is trivial and was not run: read the predicted RAM
+  address and compare it to the disc, which takes one command and would have
+  shown the verbatim copy immediately.

docs/roadmap.md

@@ -330,11 +330,17 @@ Phase 1 hands over the extents; this phase works out what each one contains.
 - [ ] The collision **cell layout is not decoded.** The payload does not walk
       as fixed-stride cells. On level 4 a table starts at payload `+5932` and
       runs **17 entries** -- deltas rise then fall -- against a 75-cell grid,
-      with no arithmetic relating the two. RAM is reshaped on load: level 1's
+      with no arithmetic relating the two. A 64-byte RAM stride looked promising
-      `24 x 16` grid dimensions appear in memory, level 0's `11 x 33` appear
+      and is **disproved** -- the longest such run is 27 records of identity
-      nowhere, so disc-side decoding has to work against the reshaped form.
+      matrices, one per level.
-      A 64-byte RAM stride looked promising and is **disproved** -- the longest
+- [x] **The collision payload is verbatim in RAM, not reshaped.** Level 0's sits
-      such run is 27 records of identity matrices, one per level. See
+      at RAM `0xac6800` for a disc address of `0x27e800`, byte-for-byte
+      identical. This **overturns** the earlier claim that the grid dimensions
+      are absent from RAM: level 0's `11 x 33` are the first two bytes of that
+      block. The earlier negative came from searching for the dimensions as a
+      `u32` pair when they are two `u16`s -- a bad pattern, not a property of
+      the data. The payload contains ascending `u32` offset tables from `+1024`
+      onward, and disc-side decoding is no longer blocked on reshaping. See
       `plan/pcsx2-verification.md`.
 - [x] `occlusion` — the PVS grid. A z/y/x tree of u16 node offsets over 4x4x4-unit
       cells, populated cells naming 128-byte masks. **412,521 cells over