The collision assert string is never referenced: the last route is closed

Followed the route I recorded as remaining -- find how the code addresses the
assert string at 0x001a8998 in .lit. It does not address it.

Level 0's program is 2,751,268 bytes. Searching it for both ways an address can
be materialised:

    address low half              0x8998    0 occurrences, word-aligned or not
    $gp-relative offset           0x99a8    0 occurrences, word-aligned or not
    exact 32-bit 0x001a8998                 0 occurrences

Validated by a positive control in the same run: the .lit load base's own low
half, 0x7c80, occurs exactly ONCE, word-aligned. A search that finds that will
find any real reference, so the zeros are real.

So no instruction and no data word in the retail level program references the
collision assert string -- not by lui/addiu, not by a literal pointer, not by a
table entry. The text is present in .lit at overlay+0xd18, and the same text also
appears in the boot binary at file offset 0xA9558, but nothing points at either.

The reading that fits: the assertion is compiled out in retail and the string is
dead data. Debug string pools routinely keep messages whose only user was an
#if-ed-out assert. The decomp's table lists this name because it recovered it
FROM THE STRING, not because it found code calling it -- which is worth noting,
because a name in a symbol table looks like evidence of a caller and is not one.

That closes the last route this file records for collision. Getting the cell
layout from the disc would need a build with assertions enabled, a debug listing,
or an independent description of R&C2's collision cell. None of those is on this
disc, and saying so is more useful than another scan.

Summary of collision, all of it now checked: the payload is verbatim in RAM, it
does not walk as fixed-stride cells, the disc-side segmentation is exhausted, the
string that would have led to the routine is unreferenced, and both of the
decomp's addresses are dead ends.

docs/formats/core-data-regions.md

@@ -3017,10 +3017,42 @@ the decomp appeared to offer are now closed:
 | `Camera_CollPrimTest` at `0x001E7A50` | lands in NOBITS, all zero |
 | `CameraCollPrimTestGridOutOfBounds` at `0x002db350` | a function with no pointer arguments |
 
-Neither address reaches the collision parser. What remains is the route already
-recorded: find how the code addresses the assert **string** at
-`0x001a8998` in `.lit`, which is not a `$gp`-relative load and is not a symbol
-address in either table.
+Neither address reaches the collision parser.
+
+### And the last route is closed too: the string is never referenced
+
+The route that remained was to find how the code addresses the assert **string**
+at `0x001a8998` in `.lit`. It does not address it. Level 0's program is
+2,751,268 bytes; searching it for both ways an address can be materialised:
+
+    address low half            0x8998    0 occurrences, word-aligned or not
+    $gp-relative offset         0x99a8    0 occurrences, word-aligned or not
+    exact 32-bit 0x001a8998               0 occurrences
+
+The method is validated by a positive control in the same run: the `.lit` load
+base's own low half, `0x7c80`, occurs exactly **once**, word-aligned. A search
+that finds that will find any real reference.
+
+So **no instruction and no data word in the retail level program references the
+collision assert string's address.** Not by `lui`/`addiu`, not by a literal
+pointer, not by a table entry. The string text is present in `.lit` at
+`overlay+0xd18`, and the same text also appears in the boot binary at file offset
+`0xA9558`, but nothing points at either.
+
+The reading that fits: **the assert is compiled out in retail and the string is
+dead data.** Debug string pools routinely keep messages whose only user was a
+`#if`-ed-out assertion. The decomp's own table lists this name because it recovered
+it from the string, not because it found code calling it.
+
+That is the last route recorded in this file, and it is closed. Reaching the
+collision cell layout from the disc would require a different kind of evidence --
+a build with assertions enabled, a debug listing, or an independent description
+of R&C2's collision cell -- none of which is on this disc.
+
+Which is the honest summary of collision after all of it: the payload is verbatim
+in RAM, it does not walk as fixed-stride cells, the disc-side segmentation is
+exhausted, the string that would have led to the routine is unreferenced, and both
+of the decomp's addresses are dead ends.
 
 ### The disassembler needed fixing first
 

docs/roadmap.md

@@ -578,12 +578,17 @@ not, which is itself a gap; this is that gap closed. None of these is a shortcut
 or an approximation -- each is a measurement this repository currently cannot
 make.
 
-- **Collision cell layout.** The payload is verbatim in RAM and does not walk as
-  fixed-stride cells; every disc-side segmentation is excluded. Needs the game's
-  own `Camera_CollPrimTest`, which lives in `.lit`. The route that would work:
-  the code addresses the assert string by something other than a `$gp`-relative
-  load -- a `%hi`/`%lo` split that does not straddle zero, a pointer table, or a
-  different section. A naive `$gp` search returns zero hits and will keep doing so.
+- **Collision cell layout.** Exhausted from the disc, and the last route is now
+  closed on evidence rather than left open. The payload is verbatim in RAM, it
+  does not walk as fixed-stride cells, and every disc-side segmentation is
+  excluded. The game's own `Camera_CollPrimTest` cannot be reached: the decomp's
+  symbol address lands in NOBITS, its assert-table address is a function with no
+  pointer arguments, and -- the decisive one -- **the assert string's address
+  occurs zero times in the 2,751,268-byte level program**, in either the address
+  or `$gp`-relative form, while a positive control in the same search finds the
+  `.lit` load base exactly once. The string is dead data; the assertion is
+  compiled out in retail. Needs a build with assertions enabled, a debug listing,
+  or an independent description of R&C2's collision cell. None is on this disc.
 - **Volumes.** A 144-byte float record table with world positions at `+0x0c`
   exists in every level and is not referenced by any `data.bin`, so it is reached
   by walking structure, and nothing ties it to volumes. Needs ground truth: a