[Blocker 5/6] Texture data loaded from corrupt heap-aliased addresses

[mgrz18]

Symptom

`loadBlock` fires with src addresses split between clean and corrupt:

• `src=0x000A0000`, `src=0x00010000` — clean (font/static textures, segment 1 / OS region)
• `src=0x00264500` — same heap region as the matrix-mystery (Blocker 3)
• `src=0x00BF7FA8` — past 8MB RDRAM (corrupt entirely)

The corrupt loads return DL stream bytes as texture data, so TEXEL0 sample produces garbage or zero.

What we know

• Setup at `lib/rt64/src/hle/rt64_rsp.cpp::setTextureImage:1160` now masks address with `& 0x00FFFFF8` (low-bits-0xB pattern, same as matrix issue)
• Shadow remap is GATED via `GE_SHADOW_TEXTURES` (off by default) — was redirecting to stale snapshots
• Width parsing (`p0(0, 12) + 1`) always reports `width=1` for GE — possible non-standard SETTIMG bit layout in F3D_Gold
• `setTile` parsing reports `line=0` for GE — same bit-layout suspicion

Try next

1. Read F3D_Gold's SETTIMG / SETTILE bit layout in `gmain.s` lines 540-700ish — verify width / line bit positions
2. Trace `g_GfxMemPos` heap layout — find why some texture pointers land at "DL chunk" addresses
3. Try snapshotting texture data into a dedicated texture-shadow region at submit time (similar to deep_shadow but for textures)

Files

• `lib/rt64/src/hle/rt64_rsp.cpp::setTextureImage` (line 1160)
• `lib/rt64/src/hle/rt64_rdp.cpp::loadBlock` (line 685)
• `lib/rt64/src/gbi/rt64_gbi_f3d.cpp::setTextureImage` (line 306, raw w0/w1 log)
• `lib/rt64/src/gbi/rt64_gbi_rdp.cpp::setTile` (line 43)

Acceptance criteria

`loadBlock` src addresses are all in valid texture-data ranges; TEXEL0 sample produces non-zero RGB for at least one frame.