Reconcile the docs after the last three corrections

The last three commits changed things the documentation still asserted in the
old direction. Fixed:

roadmap
  * 227 tests -> 238.
  * The level_overlay bullet contradicted itself: it said "the header words are
    not named" in the same breath as "+0x00 load base is 0x1A7C80". Now says
    +0x00 IS the load base and is named, +0x0c is excluded as the .lit size by
    sign (below file length on 16/27, by up to 8.9%) and remains unnamed, and the
    unnamed remainder is stated as such.
  * Section names aligned with the Phase 3 list (lvl.vtbl, lvl.camvtbl,
    lvl.sndvtbl).

core-data-regions.md
  * The claim-assertion audit still said the two PCSX2 claims were "NOT
    assertable here -- needs a savestate". They are asserted now, gated on
    GC_SSTATE, in the same file. Updated, with the two corrections that fell out
    of writing them recorded right there.
  * "that string is inside the collision routine" was never established. It is
    in the string pool, yes; the reference to it is not found. Reworded to say
    so, including the zero-hit result.

research log
  * field_00 now carries its name and the .lit/$gp/program context.
  * The field_0c falsification and the byte-order retraction are both recorded
    here as well, so the log and the format file agree.

Nothing left asserting the withdrawn anchor, and no stale test counts.

docs/formats/core-data-regions.md

@@ -1707,11 +1707,14 @@ than on a sample.
 
 ### What would actually unblock this
 
-`overlay.bin` **is the game's own code**, and the collision parser is in it --
+`overlay.bin` **is the game's own code** -- it is the level's `.lit` section,
-`Camera_CollPrimTest WARNING! - grid out of bounds! (RAR)` was located in the
+loaded at `0x1A7C80` -- and the collision debug string
-debug string pool earlier, and that string is inside the collision routine. The
+`Camera_CollPrimTest WARNING! - grid out of bounds! (RAR)` is in its string pool.
-format is therefore recoverable, but not by measuring bytes: it needs either
+So the parser is reachable. What is *not* established is the reference to it: a
-disassembly of that routine or a reference for R&C2's collision cell record.
+`$gp`-relative search for the string returns **zero** instruction-aligned hits,
+so the code addresses that string by some other means. The format is therefore
+recoverable, but not by measuring bytes: it needs disassembly of that routine or
+a reference for R&C2's collision cell record.
 
 Stating this plainly is worth more than another scan. The disc-side measurement
 space for collision is now genuinely exhausted -- the bytes are available, they
@@ -1824,17 +1827,25 @@ likely to be lost. Audit against `crates/gc-extract/tests/disc.rs`:
                                                   start_16_byte_aligned
     moby class IDs in one body slot per type     moby_class_ids_sit_in_one_slot_
                                                   per_chunk_type
-    collision payload verbatim in RAM            NOT assertable here -- needs a
+    collision payload essentially verbatim       collision_payload_is_verbatim_
-                                                  savestate, so it lives in
+                                                  in_ram  (GC_SSTATE-gated)
-                                                  plan/pcsx2-verification.md
+    tfrag pointers relocate, patches rewrite     tfrag_table_pointers_relocate_
-    tfrag patch bytes all rewritten by LOD       same -- savestate-dependent
+                                                  and_every_patch_is_rewritten
-    morphing is unobservable in that image       same -- savestate-dependent
+                                                  (GC_SSTATE-gated)
+
+The last two used to be marked "not assertable here -- needs a savestate". They
+are asserted now, in the same file, gated on `GC_SSTATE` so a checkout without
+PCSX2 skips them. Writing them as tests is what corrected two claims: the
+collision payload is 903,212 of 903,248 bytes identical rather than wholly
+verbatim, and the tfrag relocation base is the *table* address `0x848040`, not
+the block base.
 
 The split is deliberate: anything readable from the disc is asserted against the
-disc, and anything that needs a running PCSX2 is documented in the plan file with
+disc; anything that needs a running PCSX2 is asserted against a savestate when
-its method. What is *not* acceptable is a disc-readable claim living only in
+one is available, and documented in the plan file with its method when it is not.
-prose, which is how the tie `i16[3]` finding spent two commits before it had a
+What is *not* acceptable is a claim living only in prose -- which is how the tie
-test.
+`i16[3]` finding spent two commits before it had a test, and how the collision
+"verbatim" claim survived long enough to be wrong.
 
 ## An external decompilation project is the same disc, and names the overlay
 

docs/plan/level-assets.md

@@ -1693,11 +1693,30 @@ as one.
 splits out the constant block and the level-specific tail, and a real-disc test
 covers all 27 levels:
 
-    overlay: 27 levels; field_00 1735808, field_08 1;
+    overlay: 27 levels; field_00 1735808 = 0x1A7C80, field_08 1;
     field_04 37540..=45308, field_0c 2763912..=3027336
     (17 below the file length, 10 above);
     +0x10..0x1220 identical on all
 
+Later, from OpenRAC/rac2-gc-decomp (same disc, SHA-256 verified identical):
+
+    field_00  IS the .lit load base -- 0x1A7C80, constant on all 27 levels
+              because every level's literal section loads at the same address.
+              overlay.bin IS that section: it holds code and the string pool.
+    $gp      0x1A7C80 + section offset is computed against $gp = 0x1AEFF0.
+    program  seven sections: .lit .bss .data lvl.vtbl lvl.camvtbl
+              lvl.sndvtbl .text
+
+field_0c tested as the .lit size and FAILED: it is smaller than the file on 16 of
+27 levels, by up to 8.9% (level11 file 3,151,128 vs field_0c 2,870,792). Excluded
+by sign, not by a near miss. Still unnamed.
+
+The collision assert string was then used as an anchor and the first attempt was
+WRONG -- a byte-order bug, recorded in core-data-regions.md. The PS2's MIPS is
+little-endian, so an I-type immediate is word bytes 0 and 1; searching bytes 1..3
+matches opcode/$rs instead and manufactured a single convincing "hit". Corrected,
+the count is zero. The anchor is NOT established.
+
 **`+0x0c` is not the file length.** It was recorded as one on the strength of the
 first levels measured, where it sat close to the file end. Across all 27 it falls
 on **both sides** -- below on 17, above on 10 -- so it is an ordinary

docs/roadmap.md

@@ -25,7 +25,7 @@ early, while they are still cheap to retire.
       `core_index` class tables, `tfrag` (format, topology, textures, LOD,
       normals, colour), `occlusion`, `sky`, `moby`, `collision` framing and
       header, `shrub` (blob, packets, palette, billboard), the post-shrub
-      `chunks` container, `sound_bank` framing and `level_overlay`. 227 tests
+      `chunks` container, `sound_bank` framing and `level_overlay`. 238 tests
       green against the real disc. **What is open is naming, not locating** --
       see the Phase 2 list for the four types that still have no decoded
       fields: `tie` vertices, collision cells, `SBlk` records, `volumes` and
@@ -399,11 +399,14 @@ Phase 1 hands over the extents; this phase works out what each one contains.
       length, falling below it on 17 levels and above on 10. The debug string
       pool it opens with carries `Camera_CollPrimTest WARNING! - grid out of
       bounds! (RAR)`, independent support for reading the collision payload's
-      two leading `u16`s as grid dimensions. **The header words are not named
+      two leading `u16`s as grid dimensions. `+0x00` **is** the load base of
-      and the level-specific tail is not structured yet**; the Phase 3
+      the section this file is, `0x1A7C80`, constant on all 27 levels because
-      seven-section parser and relocation are untouched. The seven sections are
+      every level's `.lit` loads there. `+0x0c` is **not** the `.lit` size -- it
-      now named (`.lit .bss .data vtbl camvtbl sndvtbl .text`) and `overlay.bin`
+      falls *below* the file length on 16 of 27 levels, by up to 8.9%, so it is
-      is the `.lit` section, whose `+0x00` load base is `0x1A7C80`.
+      excluded by sign -- and it is still unnamed. **The remaining header words
+      are unnamed and the level-specific tail is not structured yet**; the
+      Phase 3 seven-section parser and relocation are untouched, though the
+      seven sections are now named (`lvl.vtbl`, `lvl.camvtbl`, `lvl.sndvtbl`).
 - [x] **The post-shrub chunk container.** A 16-byte header, a 10-byte zero gap,
       then offsets tagged `0xF0000000 | low24` resolving to `chunk_start + low`;
       header byte 14 is the record count, equal to `offsets.len()` on 1,123 of