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