KB: retract the GPU-contention claim -- the -net node glitch is MP-path-specific (two solo instances both clean)

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

context/multiplayer.md

@@ -37,16 +37,19 @@ 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.
+- ⚠ **`-net` NODE RENDER GLITCH — OPEN (observed live 2026-07-09, cause NOT yet found):** in a 2-node
+  session ONE window comes up visually GLITCHED FROM LOAD (before any death) — shadow clipping, camera
+  stuck inside/blocked, targeting/firing feels dead — while the OTHER is fine. **Isolated by test, not
+  theory:** (a) a SOLO instance is perfect; (b) **TWO SOLO instances (no `-net`) are BOTH perfect**
+  (each logs `MECH under boresight … IN WEAPON RANGE`, no device fallback/error, both hardware HAL
+  devices). So it is **NOT** a two-D3D9-apps-on-one-GPU / device-contention issue (an earlier note
+  claimed that — WRONG, retracted) and NOT the warp/respawn (from-load, pre-death). It is **specific
+  to the MP `-net` path** — the console-driven mission-start ladder / replication doing something to
+  ONE node's render+input state, asymmetrically (the two nodes differ in launch order, affinity,
+  net port, BT_MP_NET, BT_MP_FORCE_DMG). CAUSE UNKNOWN — next step: determine WHICH node glitches
+  (A@1501 vs B@1601) and correlate, then audit the MP viewpoint/camera/HUD setup vs the (clean) solo
+  path. Does NOT affect the pod (one instance per machine). Dev workflow: trust the SOLO window for
+  visual/gameplay checks; the 2-node logs are still trustworthy for replication/netcode logic.
 - **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