KB: one-box 2-instance render glitch is a two-D3D9-apps-on-one-GPU artifact (solo is clean)

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

context/multiplayer.md

@@ -37,6 +37,16 @@ all connect. The **CONSOLE** (operator station — ABSENT from every archive) de
 emulator** (⚠ `NotationFile::ReadText` expects NUL-SEPARATED lines). [T2]
 
 ## Verified milestones (one box, two instances)
+- ⚠ **ONE-BOX 2-INSTANCE RENDER CAVEAT (observed live 2026-07-09):** with two `btl4.exe` sharing a
+  single GPU, ONE window comes up visually GLITCHED FROM LOAD — shadow clipping, camera stuck
+  inside/blocked, degraded input (targeting/firing feels dead). A **solo** instance (`-egg TEST.EGG
+  BT_SPAWN_ENEMY=1`) renders + targets + fires perfectly (log: `MECH under boresight … IN WEAPON
+  RANGE mechPicks=59`). So this is a **two-D3D9-apps-on-one-GPU** artifact (the 2nd device to init
+  gets degraded state), NOT a game-logic/warp/respawn bug — and it does NOT affect the pod (each pod
+  is its own machine). Consequence for dev: trust the SOLO window for visual/gameplay checks; use the
+  2-node box only for REPLICATION/netcode logic (which the logs confirm independent of the glitch).
+  If single-box 2-window visual testing is ever needed, the fix is in per-instance D3D device/resource
+  init (unproven; likely a shared global or device-state clobber), not the game code.
 - **P6 smoke test:** two instances share a world — console egg → TCP mesh → synchronized start →
   bidirectional entity replication (each renders its own mech + the peer's REPLICANT), 0 crashes.
 - **Movement replication:** A's mech WALKS on B's screen (the replicant tracks the master to ~1.5u via