D95: raise the PC mempool ceiling to reclaim ~4 MB of unused DRAM

The N64-fidelity mempool end (0x702F4400, tlbmanageGetTlbAllocatedBlock)
leaves ~5 MB of live, mapped, unused DRAM below the 8 MB top (only
animations_frame_buffer at 0x707FFD30 lives up there). PC structs are
larger everywhere, so the per-level -m* budget no longer fits and
MEMPOOL_STAGE OOMs (zbufAllocate spins in mempAllocBytesInBank). Raise
the ceiling to 0x70700000; the ~4 MB gain goes to MEMPOOL_STAGE.

With this + the reapplied 2x g_GfxBuffers (128f7644), -level_09 renders
~5 frames (previously: OOM hang, or non-deterministic overrun within
seconds). It then still faults in bgScissorCurrentPlayerView writing at
0x70800000 -- but deterministically at ~frame 5 and regardless of -mgfx
size (tested up to 1.6 MB/half), so that is a RUNAWAY GDL append in the
prop-render path (chrpropsRenderPass/chrpropRender), not a buffer-size
problem. Next blocker.

port/src/n64stubs.c

@@ -93,7 +93,17 @@ void tlbmanageTranslateLoadRomFromTlbAddress(u32 address)
 }
 u8 (*tlbmanageGetTlbAllocatedBlock(void))[TLB_BLOCK_SIZE]
 {
-    return (u8 (*)[TLB_BLOCK_SIZE])0x702F4400;
+    /* D95: the N64-fidelity ceiling is 0x702F4400 (see above). On PC the
+     * game's structs are larger everywhere (16-byte Gfx, 24-byte struct tex,
+     * pointer-widened records...) so the same per-level -m* budget no longer
+     * fits — MEMPOOL_STAGE OOMs (zbufAllocate spins in mempAllocBytesInBank).
+     * There is ~5 MB of live, mapped, otherwise-unused DRAM between the N64
+     * ceiling and the top of the 8 MB region (only animations_frame_buffer
+     * lives up there, at 0x707FFD30). Reclaim ~4 MB of it for the mempool
+     * area; the extra goes to MEMPOOL_STAGE (boss.c:218 gives STAGE
+     * everything that isn't the fixed PERMANENT bank). Stays well clear of
+     * animations_frame_buffer. */
+    return (u8 (*)[TLB_BLOCK_SIZE])0x70700000;
 }
 
 /* --- K&R libc helpers (IDO provided these; the host libc does not) ------- */