Add TeslaRel410 (original 4.10 games under DOSBox-X emulation)

- Ecosystem doc: new section on the TeslaRel410 project — custom
  DOSBox-X fork HLE-emulating the Division VPX board to run the
  original, unmodified Tesla 4.10 BattleTech/Red Planet DOS binaries
  on current Windows 10 pod hardware (RIO COM1 / plasma COM2
  passthrough). Networking facts for SiteLink: WATTCP (real TCP/IP)
  via NetNub over emulated NE2000 bridged by pcap -> routable in
  principle; BOOTP is broadcast -> site-local provisioning.
- Clarified BT411 and RP411 as the two native Win32 Tesla 4.10
  reconstructions (per operator), complementary to the emulation path.
- Brainstorm: new game-linking subsection for the emulated originals +
  open question 11 (NetNub cross-subnet addressing, 30 Hz sim latency
  tolerance).
- CTCL naming note: provenance question is out with VWE veterans.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

docs/BRAINSTORM.md

@@ -153,10 +153,28 @@ Fine between trusted operators, but do it deliberately:
 - Console-must-stay-connected quirk means the WAN link drop kills the match — argues for
   running the BT console *at the site with the most pods*, or fixing the engine bug.
 
-### Red Planet
+### Red Planet (RP411 reconstruction)
 - Same console-directed model (Munga TCP 1501). Park until BT411 learnings land — shared
   engine lineage means most answers transfer.
 
+### Original Tesla 4.10 games under emulation (TeslaRel410)
+- When the DOSBox-X/VPX emulator matures, the *original* BT/RP binaries land on
+  current pod hardware speaking their original network stack: **WATTCP (real
+  TCP/IP) via NetNub**, surfaced through NE2000-emulation bridged onto the bay LAN
+  via pcap. Because it's plain IP with the emulated pod holding a real bay address,
+  the routed-VPN model extends to them *in principle* unchanged.
+- Site-local pieces: BOOTP (broadcast) needs an answerer or static config per site —
+  same "provision locally, play routably" pattern as everything else.
+- Unknowns to test (cheap — emulator instances run on any PC, no cockpit needed):
+  NetNub discovery/mesh addressing across subnets, and the latency tolerance of a
+  30 Hz 1996 lockstep-era sim. Fold into the Phase 0 netem lab once the emulator
+  reaches its networking phase (PLAN.md Phase 6).
+- Strategic note: BT411/RP411 (native, netcode we can patch) and TeslaRel410
+  (faithful, netcode frozen in 1996) are complementary. If the original protocol
+  proves WAN-hostile, the answer may be "emulated originals for local play, native
+  reconstructions for cross-site" — SiteLink shouldn't promise WAN play for the
+  emulated path until measured.
+
 ## 6. Shared services (the `10.0.0.0/24` rack)
 
 | Service | Notes |
@@ -211,6 +229,10 @@ worth a small design of its own later.
    whether federation (§4.3) is ever needed.
 10. **WAN-drop behavior** — for each linked flow, what breaks when the tunnel drops
     mid-match, and does the bay cleanly fall back to stand-alone?
+11. **NetNub over routed subnets (TeslaRel410)** — how do the original 4.10 games
+    discover/address each other (read `CODE\*\MUNGA_L4\NETNUB\` + `L4NET` lineage)?
+    Broadcast-dependent or console-directed like their descendants? And what RTT does
+    the 30 Hz 1996 sim tolerate?
 
 ## 9. Phased roadmap (strawman)
 

docs/PODBAY-ECOSYSTEM.md

@@ -77,7 +77,8 @@ machines on the internet.
     constants are `_ECTCL_Console` / `_ECTCL_Launcher`; the API is Tesla-centric
     (`CTCL_GetTeslaCount`, `STeslaInfo`, `MAX_TESLAS 16`, `MAX_CAMERAS 4`) and
     coin-op-aware (`CTCL_CoinDisplay`). So "Console↔Tesla Control Layer/Link" is our
-    best reading — treat it as inference, not fact.
+    best reading — treat it as inference, not fact. *(Provenance question is out
+    with VWE veterans — update here when word comes back.)*
   - **Game-agnostic:** app-type constants `_EAT_MW4` and `_EAT_RP` (`ctcl_params.h`)
     — the same control layer drives both Firestorm and Red Planet. One layer for
     SiteLink to reason about, not two.
@@ -92,7 +93,7 @@ machines on the internet.
 - **2016 release integrated Mumble** for voice (FS507D postinstall) — cross-site voice is
   a solved problem: one Mumble server on the shared network.
 
-### BT411 (classic BattleTech, Tesla 4.10 reconstruction)
+### BT411 (classic BattleTech — Tesla 4.10 reconstruction, native Win32)
 - **Console-push model over plain TCP:** the console connects to each pod's `-net <port>`
   listener (convention 1501/1601), streams the mission egg in 1040-byte framed chunks,
   then sends `RunMission` twice (`BT411\tools\btconsole.py` documents the full wire
@@ -104,10 +105,45 @@ machines on the internet.
   the `[pilots]` list carry literal IPs? → see BRAINSTORM open questions).
 - Status: entity/movement replication works; cross-pod combat in progress.
 
-### Red Planet (RP411 / RP 4.11.4)
-- MUNGA engine, console game-control via **Munga protocol, TCP 1501** (vendored
-  `Munga Net.dll` in TeslaConsole). Same console-directed model as BT411 (shared engine
-  lineage — `MUNGA_L4\L4NET.CPP`).
+### Red Planet (RP411 — classic Red Planet, Tesla 4.10 reconstruction, native Win32)
+- Same lineage as BT411: the classic Tesla 4.10 title carried forward as a native
+  Win32 port (MUNGA engine + L4 platform layer, DX9). Console game-control via
+  **Munga protocol, TCP 1501** (vendored `Munga Net.dll` in TeslaConsole 4.11.4).
+  Same console-directed model as BT411 (shared `MUNGA_L4\L4NET.CPP`).
+
+### TeslaRel410 — the *original* Tesla 4.10 games under emulation
+The third route to the classic titles (`C:\VWE\TeslaRel410`): don't port the game —
+**emulate the 1996 pod computer** and run the original, unmodified DOS executables on
+the current Windows 10 cockpit hardware. Full plan: `TeslaRel410\emulator\PLAN.md`.
+
+- **What it is:** archival snapshot of the 1994–96 Tesla:BattleTech and
+  Tesla:Red Planet source + content (Borland C++ 5.0 / TASM, MUNGA + MUNGA_L4), plus
+  complete runnable DOS installs (`sda4\BTLIVE`, `sda4\RPLIVE`).
+- **The approach:** a custom **DOSBox-X fork** whose main addition is a
+  high-level-emulation device impersonating **Division Ltd.'s VPX render board** at
+  its host interface (INMOS C012 link adapter, polled I/O at port 0x150) and
+  rendering via OpenGL. The cockpit's real **RIO (COM1)** and **plasma display
+  (COM2)** are passed through to physical serial ports so the game's own 1996
+  drivers run the actual cockpit hardware; SB16 emulation feeds the speakers.
+- **Ultimate goal:** deploy to the current pods — power-on → attract mode, playable
+  in the cockpit (plan estimates ~3–5 months focused work; gauges deferred).
+- **Networking — the SiteLink-relevant part:** the original pods networked over
+  Ethernet using **WATTCP (DOS TCP/IP, with BOOTP) via VWE's NetNub layer**
+  (`CODE\*\MUNGA_L4\NETNUB\`). The emulator exposes this through **NE2000 emulation
+  bridged via pcap** — i.e. the emulated game gets a real presence on the bay LAN
+  with its own MAC/IP. Consequences:
+  1. It's plain IP — in principle it routes across a SiteLink VPN like any other
+     bay host (an emulated pod could be a `10.0.y.x` address).
+  2. **BOOTP is broadcast** — the boot-time address assignment is site-local; each
+     site needs its own BOOTP answerer (or static WATTCP config). Same pattern as
+     SecureConfig beacons: provisioning local, play routable.
+  3. Pod-to-pod/console addressing inside NetNub (discovery, mesh formation,
+     latency assumptions of a 30 Hz 1996 sim) is unverified for cross-subnet play —
+     open question, testable cheaply since emulator instances run on any PC.
+- **Relationship to BT411/RP411:** two complementary strategies for the same
+  titles — native reconstruction (BT411/RP411, modern netcode we control) vs
+  faithful emulation (TeslaRel410, original binaries, original protocols). SiteLink
+  should assume *both* may want cross-site play eventually.
 
 ### PQS — Pod Queue System (front of house)
 - XAMPP (Apache/PHP/MySQL) app: registration, callsigns, combined queue displays,