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>

engine/MUNGA/APP.cpp

@@ -1386,15 +1386,22 @@ void
 
 			console_host = GetHostManager()->GetConsoleHost();
 			if (
-				(console_host == NULL) ||
+				!gConsoleMarshalsLaunch &&
 				(
-					console_host != NULL &&
-					console_host->GetConnectStatus() != Host::OnLineConnectionStatus
+					(console_host == NULL) ||
+					(
+						console_host != NULL &&
+						console_host->GetConnectStatus() != Host::OnLineConnectionStatus
+					)
 				)
 			)
 			{
 				//
-				// In the absence of the console just post the message to run
+				// In the absence of the console just post the message to run.
+				// An IN-PROCESS console (hosted network mission) has no
+				// connection to this pod but still owns the launch -- the
+				// gConsoleMarshalsLaunch flag holds us at WaitingForLaunch
+				// until every pod in the mesh is staged (BT412).
 				//
 				RunMissionMessage run_mission_message;
 				Post(DefaultEventPriority, this, &run_mission_message);

engine/MUNGA/APPMGR.cpp

@@ -17,6 +17,11 @@ Logical gConsoleLossEndsMission = False;
 // own the mission clock).  NULL when unregistered.
 void (*gPerFrameHook)() = NULL;
 
+// BT412: the in-process console owns the launch of a hosted network mission --
+// when True, a staged pod stays at WaitingForLaunch instead of self-launching,
+// so the console can launch the whole mesh at once (APP.cpp).  Default False.
+Logical gConsoleMarshalsLaunch = False;
+
 ApplicationManager* ApplicationManager::CurrentAppManager = NULL;
 
 ApplicationManager::ApplicationManager(HINSTANCE hInstance, HWND hWnd, Scalar frame_rate) : Node(ApplicationManagerClassID), runningApplications(this)

engine/MUNGA/APPMGR.h

@@ -12,6 +12,13 @@ extern Logical gConsoleLossEndsMission;
 // BT412: per-frame observer hook (the LocalConsole marshal's game-thread tick).
 extern void (*gPerFrameHook)();
 
+// BT412: when True, a pod at WaitingForLaunch does NOT self-launch even with no
+// connected console -- the IN-PROCESS console (hosted network mission) owns the
+// launch and holds every pod at WaitingForLaunch until the whole mesh is staged,
+// then dispatches RunMission everywhere at once.  See APP.cpp.  (Ported from
+// RP412's engine mod; default False = the stock self-launch behavior.)
+extern Logical gConsoleMarshalsLaunch;
+
 class ApplicationManager : public Node
 {
 public: