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/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