The decomp names both collision functions; their addresses are not ours

rac2-gc-decomp names the two collision entry points:

    Camera_CollPrimTest   0x001E7A50   camera-to-world boundary check
    MB_CheckCollPill      0x001E8890   pill/capsule check for moby instances

That looked like the collision unblock. The $gp string search has failed twice
now, and a named function at a known address is exactly what it failed to
produce.

They are not usable. Checked against levels 0, 5, 13 and 26 with
parse_overlay_sections:

    Camera_CollPrimTest @ 0x1e7a50  ->  section 1, kind 8 (NOBITS)
    MB_CheckCollPill    @ 0x1e8890  ->  section 1, kind 8 (NOBITS)

Both land inside the level program's zero-filled section. Every byte is zero and
the following 256 bytes contain no non-zero byte at all -- code cannot be there.
Same on all four levels, so it is not a level with an unusual layout.

So the addresses belong to a different address space than a parsed level overlay.
Most likely the boot executable's own layout, or the v2.00 build; that repository
covers both. SCUS_972.68 is USA v1.01 and our disc matches it exactly, but that
fixes the disc, not which program's address space a symbol address is quoted in.
The disc matching is exactly the kind of check that looks sufficient and is not --
a disc can pin the bytes and still leave you looking in the wrong program.

Worth noting the method that caught it. The temptation was to take the address,
open the overlay at that offset, and start reading instructions. What settled it
was checking which section the address falls in, and its KIND: a NOBITS section is
zero-filled by definition, so an address inside one is a contradiction rather than
a lead. The section table made that a two-line check.

This closes the shortest route to the collision cell layout, for a checkable
reason rather than a vague one. The route that remains is the one already
recorded: find how the code addresses the Camera_CollPrimTest assert string, which
is not by a $gp-relative load.

docs/formats/core-data-regions.md

@@ -2907,3 +2907,33 @@ size.
 
 Asserted in `sound_bank_sblk_body_head_carries_the_daw_size_twice`. The remainder
 of the body -- a per-sound record table -- is still undecoded.
+
+## The decomp names the collision functions, but their addresses are not ours
+
+`OpenRAC/rac2-gc-decomp` names both collision entry points:
+
+    Camera_CollPrimTest   0x001E7A50   camera-to-world boundary check
+    MB_CheckCollPill      0x001E8890   pill/capsule check for moby instances
+
+These looked like the collision unblock: a named function at a known address is
+exactly what the `$gp` string search failed to produce. They are not usable.
+Checked against four levels -- 0, 5, 13, 26 -- with `parse_overlay_sections`:
+
+    Camera_CollPrimTest @ 0x1e7a50  ->  section 1, kind 8 (NOBITS)
+    MB_CheckCollPill    @ 0x1e8890  ->  section 1, kind 8 (NOBITS)
+
+Both land inside the level program's zero-filled section. Every byte there is
+zero, and the following 256 bytes contain no non-zero byte at all. Code cannot be
+there, and both addresses are in the same place on all four levels.
+
+So those addresses belong to a different address space than a parsed level
+overlay -- most likely the boot executable's own layout, or the v2.00 build, both
+of which that repository also covers. `SCUS_972.68` is USA v1.01 and our disc
+matches it exactly, but that fixes the *disc*, not which program's address space a
+symbol address is quoted in.
+
+This closes the shortest route to the collision cell layout that the decomp
+appeared to offer, and it closes it for a checkable reason rather than a vague
+one. The route that remains is the one already recorded: find how the code
+addresses the `Camera_CollPrimTest` assert string, which is not by a `$gp`-relative
+load.