Decode the overlay's load base, from its own profiler table

Range measured: all 27 levels' overlays.

The overlay carries the game's profiler menu definition -- a run of 8-byte
padded names (normal, camera, cam+chr, volume, bars, render, mobys, ties,
shrubs, cpu/gpu, occl, ...) followed by runs of absolute RAM addresses that
point back at those same names. On every level the four addresses after
normal/camera/cam+chr/volume, each minus its target name's overlay offset, give
the same number: 1,735,792.

That is field_00 - 16, where field_00 is the header word that read 1,735,808 on
all 27 levels with nothing attached to it. The overlay is loaded with its
16-byte header stripped, so overlay offset X sits at RAM X + 1,735,792.
OverlayHeader::ram_address carries it, and the disc test asserts the derivation
holds on all 27 levels.

Confirmed, not only derived: level 0's RAM 0x1acf80 holds
"normal\0camera\0cam+chr\0volume\0", byte-identical to overlay 0x5310, and
0x5310 + 1735792 == 0x1acf80. All four names land where the overlay's own table
says. `gc-trace verify-overlay-base` runs that check, savestate-gated the same
way as the tie and tfrag ones.

The overlay is relocated, not copied: only 37.67% of level 0's is
byte-identical at the base, and the 256-entry sine table -- at overlay 0xb650c
-- is not at 0xb650c + base. So the base locates the overlay's image, but
individual tables inside it move. That is the shape of a loader applying
relocations, and it means the base is necessary but not sufficient for reading
the game's tables.

The value of the base is that any overlay offset can now be carried to a RAM
address, which is the prerequisite for reading the game's live level state --
the thing the tie relocation and tfrag lighting checks had to work around.

Two things get deleted rather than finished. The collision u16 table was probed
four ways -- magnitude distribution, level-independence, run starts, run
lengths -- and every one came back level-dependent: the run-start pattern is
identical on 1 of 19 levels. So the first 1024 bytes of the collision payload
are data, not a fixed table, and nothing was decoded. Recorded as the negative
it is rather than left as four half-findings.

docs/roadmap.md

@@ -415,6 +415,12 @@ Phase 1 hands over the extents; this phase works out what each one contains.
       `+0x20` is self-limiting: entries run while strictly inside the region.
       **The word at `+0x0c` is not a count** -- it disagrees with the table on
       most levels and reads 196,617 on level 2 against 4 sub-objects.
+- [x] The **overlay's load base is `field_00 - 16` = 1,735,792**, derived from
+      the overlay's own profiler table (whose absolute addresses point back at
+      its names, on all 27 levels) and **confirmed in RAM**: all four profiler
+      names land where the base predicts. Any overlay offset can now be carried
+      to a RAM address. The overlay is *relocated*, not copied: only 37.67% is
+      byte-identical at the base, so tables inside it move.
 - [~] `volumes` — **still not identified, but a candidate exists.** Every level's
       `gameplay.bin` carries a table of **144-byte float records** with world
       positions at `+0x0c`, preceded by an all-zero record (levels 0-9: 23 to 612