docs: correct the stale 256 KiB RAM claim in BRINGUP_LOG

The '256 KiB / driver only models 256 KiB of main RAM' note was from an early
dump and is wrong.  The driver maps 0x00000000-0x01ffffff, which on this
bit-addressed space is 0x2000000 units = 0x400000 bytes = 4 MiB, confirmed
empirically (mainram share size == 4194304).  Keep the correction with the
original so the stale figure cannot mislead again.

harness/mame/BRINGUP_LOG.md

@@ -197,11 +197,17 @@ percentage counts uninitialised bitmap data because the active pixels are never
 
 ### RAM dump (frame 200, via the shared RAM pointer)
 
-`vt1200-ram-200.bin` is **262,144 bytes = 256 KiB** — and that size is itself a finding,
-because the map range `0..0x1fffff` with 8 address units per byte means **the driver
-only models 256 KiB of main RAM**. The real VT1200 has 1 MiB onboard plus up to
-3 × 1 MiB SIMMs (service guide), and POST runs a memory test. **Enlarging the RAM
-mapping is now a prime suspect and is a cheap experiment.**
+`vt1200-ram-200.bin` is **262,144 bytes = 256 KiB**.
+
+> **CORRECTION (2026-10-16).** The 256 KiB figure above is **stale** — it is from an
+> early dump, and the inference built on it ("the driver only models 256 KiB") is
+> **wrong**. The driver today maps `map(0x00000000, 0x01ffffff)`; on this space at
+> 8 address units per byte that is `0x2000000` units = **0x400000 bytes = 4 MiB**,
+> confirmed empirically (`machine.memory.shares[':mainram'].size == 4194304`). The
+> old range was `0x1fffff` (256 KiB) — one extra digit. So the mapping is already
+> 4 MiB and does **not** need enlarging. This stale line misled a reader once; keep
+> the correction with it. (The separate question of what the firmware *concludes*
+> about memory — the SIMM presence bits at `@0x5000000` — is unaffected.)
 
 Contents of what we do model: full of 32-bit **ROM pointers** (`0x3FD24A90`, `0x3FD2C800`,
 …) and resident strings (`$Header: init.c,v 1.3 …`, `DWT TCP/IP Rev 1.0`,