Two-pod LAN mesh test: multiplayer verified through the seam

tools/two-pod-test.ps1 stands up two -net pods on loopback and
marshals them with a minimal console feeder speaking the Munga
protocol (TeslaSuite vendored Munga Net.dll): state polling, egg
chunk delivery with ACK-after-mesh, RunMission when both pods reach
WaitingForLaunch, StopMission(0) at time expiry, EndMission score
intake.

First run passed clean: pod A listened on its game port, pod B
connected from its bound port, both ACKed after the mesh completed,
raced the same 60s mission on Wiseguy's Wake, stopped on command,
and reported final scores. The deterministic TCP mesh works end to
end through the NetTransport seam - the feeder logic is exactly the
marshal the Steam lobby owner will run in-process.

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

docs/RP412-FRONTEND-DESIGN.md

@@ -105,6 +105,16 @@ front end (owner collects FakeIPs/loadouts via lobby data, builds and
 distributes the canonical egg, runs the RPL4CONSOLE marshal) → install
 with `NetTransport_Set` at WinMain when launched under Steam.
 
+**Multi-pod verified (2026-07-12):** `tools/two-pod-test.ps1` runs two
+`-net` pods on loopback (console ports 1501/1601 → game ports 1502/1602)
+marshaled by a minimal console feeder built on TeslaSuite's vendored
+`Munga Net.dll`. Confirmed end to end through the seam: egg chunks +
+per-pod ACK after "All connections completed!" (pod A listened, pod B
+connected from its bound game port — the deterministic mesh), both pods
+raced the same 60s mission, StopMission(0) ended it, and both pods
+returned EndMission final scores. The feeder is exactly the marshal the
+Steam lobby owner will run in-process.
+
 ## 4. Implementation options (decide here)
 
 **A. In-engine front end (recommended).** Port the egg builder (~300 lines: