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.

crates/gc-formats/src/overlay.rs

@@ -65,6 +65,13 @@ pub const OVERLAY_CONSTANT_BLOCK_END: usize = 0x1220;
 #[derive(Debug, Clone, Copy, PartialEq, Eq)]
 pub struct OverlayHeader {
     /// The word at `+0x00`. Reads `1735808` on all 27 levels.
+    ///
+    /// It is the **load address of the payload**: the overlay is loaded with
+    /// its 16-byte header stripped, so overlay offset `X` sits at RAM
+    /// `X + field_00 - OVERLAY_HEADER_SIZE`. See
+    /// [`OverlayHeader::ram_address`] for how this was established -- the
+    /// overlay's own profiler table carries absolute addresses pointing back
+    /// at its strings, and four of them agree on the base on all 27 levels.
     pub field_00: u32,
     /// The word at `+0x04`. Level-specific; 37,540 on level 24 through 45,308
     /// on level 2, and a multiple of 4 on every level.
@@ -79,6 +86,12 @@ pub struct OverlayHeader {
 }
 
 impl OverlayHeader {
+    /// Where the overlay's payload, and therefore offset `X`, sits in RAM:
+    /// `X + field_00 - OVERLAY_HEADER_SIZE`.
+    pub fn ram_address(&self, offset: usize) -> u64 {
+        offset as u64 + self.field_00 as u64 - OVERLAY_HEADER_SIZE as u64
+    }
+
     /// Parse the header, bounds-checked against `region`.
     pub fn parse(region: &[u8]) -> Result<Self> {
         let mut r = Buf::new(region);