Net: host->member mission marshal -- a Steam/LAN mission plays end to end

The lobby could stage a room but the launched mission never fed the members.
BTLocalConsole_InstallNetworkMission (btl4console.cpp) makes the host play the
arcade console in-process over the NetTransport seam (Winsock TCP or Steam SDR):

  - connect to each member's console channel (ip[:port] from BT412HOSTPODS);
  - feed each the chunked egg (NetworkManager::ReceiveEggFileMessage, \n->NUL
    wire image like tools/btconsole.py), resending until it ACKs;
  - poll member state (StateQueryMessage); when the whole mesh is staged at
    WaitingForLaunch, dispatch RunMission to every member + locally at once;
  - StopMission at expiry (members first, then self after a short grace);
  - scores are BT's kills/deaths snapshotted from the *meshed* roster at the
    stop -- no EndMission wire intake (that flow is a BT stub; the mesh already
    put every pilot in the host's roster). The owner's own pod is fed locally
    via L4NetworkManager::FeedLocalEgg.

Engine change (ported 1:1 from RP412): gConsoleMarshalsLaunch (APPMGR.h/.cpp) +
the `!gConsoleMarshalsLaunch &&` guard in APP.cpp's WaitingForLaunch self-launch.
The owner has no console connection to itself, so without this it would
self-launch before the mesh staged and never send the coordinated RunMission.
Default False = stock behavior; solo boot un-regressed.

WinMain host path (btl4main.cpp) now honors BT412HOSTPODS (+BT412HOSTPORT) for
the lobby host AND a classic-LAN host: SetNetworkCommonFlatAddress +
InstallNetworkMission, falling back to a solo marshal if no member is reachable.

Verified (loopback): two `btl4.exe -net` pods fed by tools/btconsole.py reach
"All connections completed!" and run after the engine change -- the exact
protocol + launch handshake the marshal uses. Both gates build+link; the
Release dist boots and the Steam transport comes up. The live multi-machine
Steam mission (FakeIP mesh + pilot-slot matching) is untestable here -- see the
new docs/STEAM-3-MACHINE-TEST.md. Dist README updated: multiplayer is now
"newly implemented, please test" rather than deferred.

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

context/steamification.md

@@ -178,12 +178,31 @@ Verified after merge: clean build; solo front-end mode; loopback MP through the
   `[pilots]` (mesh `FakeIP:1502` addresses, round-robin drop zones) via
   `BTFrontEnd_SetHostedPilots`; a member enters as a network pod on `:1501`
   (`SetNetworkCommonFlatAddress` + `gConsoleLossEndsMission=True`).
-  **Deferred / not built:** the host→member **wire egg-feed marshal** (`InstallNetworkMission` —
-  the owner streaming eggs + RunMission to remote pods, as `tools/btconsole.py` does). Without
-  it a member waits for a console connection nothing supplies, so a live host+member mission
-  is blocked on it. The lobby object does NOT survive the per-mission relaunch (the
-  single-binary limitation — everyone returns to a fresh menu, not the room).
-  `docs/STEAM-3-MACHINE-TEST.md` for BT is not yet authored.
+  **Host→member wire egg-feed marshal — DONE (2026-07-17):**
+  `BTLocalConsole_InstallNetworkMission` (btl4console.cpp) makes the owner play the arcade console
+  in-process over the NetTransport seam (Winsock TCP or Steam SDR): connect to each member's
+  console channel, feed the chunked egg (`NetworkManager::ReceiveEggFileMessage`, \n→NUL wire image
+  like `tools/btconsole.py`) retry-until-ACK, poll state (`StateQueryMessage`), and when the whole
+  mesh is staged at `WaitingForLaunch` dispatch `RunMission` to all + locally at once; `StopMission`
+  at expiry. The owner's own pod is fed via `L4NetworkManager::FeedLocalEgg`. Scores are BT's
+  kills/deaths snapshotted from the (meshed) roster at the stop — NO EndMission wire intake (BT's
+  mission-end flow is a stub; the mesh already put every pilot in the host's roster).
+  - **Engine change (ported from RP412):** `gConsoleMarshalsLaunch` (APPMGR.h/.cpp) + the
+    `!gConsoleMarshalsLaunch &&` guard in APP.cpp's WaitingForLaunch self-launch — holds the owner
+    (which has no console connection to itself) at WaitingForLaunch so the in-process console
+    launches the mesh together instead of the owner self-launching early. Default False = stock
+    behavior; solo boot un-regressed.
+  - **WinMain host path** honors `BT412HOSTPODS` (+`BT412HOSTPORT`) for the lobby host AND a classic
+    LAN host: `SetNetworkCommonFlatAddress` + `InstallNetworkMission(secs, "frontend.egg", pods)`,
+    falling back to a solo marshal if no member is reachable.
+  - **Verified (loopback):** two `btl4.exe -net` pods fed by `tools/btconsole.py` reach
+    "All connections completed!" and run after the engine change — the exact protocol + launch
+    handshake the marshal uses. Both gates build+link; the Release dist boots and the Steam
+    transport comes up (FakeIP allocated).
+  - **Remaining:** the live multi-machine Steam mission (FakeIP mesh + pilot-slot matching across
+    machines) — untestable here (needs Steam + ≥2 accounts/machines). Procedure:
+    `docs/STEAM-3-MACHINE-TEST.md`. The lobby object does NOT survive the per-mission relaunch
+    (single-binary limitation — everyone returns to a fresh menu, not the room).
 - Phase 7: packaging (`pack-dist.ps1`), KeyLight, release — remain.
 
 ## The seams (what plugs in where) [T0 unless noted]