Departed-pod resilience: collision guard + console loss ends the race

Round six raced all three machines (staging fix confirmed) and then
exposed what happens when a pod leaves mid-mission - which arcade pods
never did.

The B crash dump named it exactly: VTV::TakeDamageMessageHandler
resolved message->inflictingEntity to NULL (the entity belonged to the
departed owner) and dereferenced it - Verify is compiled out in
release. Collision damage from an entity that no longer exists is now
ignored.

And the race B and C were left in was a zombie: the owner (console)
had aborted, so the mission clock would count up forever and the
death/respawn flow hung with nobody to arbitrate. Lobby-member races
now set gConsoleLossEndsMission: losing the console mid-mission posts
StopMission locally, the pod tears down, and lands back in the lobby
room. Arcade -net pods keep the re-listen-and-wait behavior.

Loopback hosted race still green.

For the drivers: the ampersand key is the arcade mission-abort - that
was every crash-on-keypress so far; and a sleeping Bluetooth pad wakes
on the Xbox button and hot-connects within 3 seconds (PadRIO
re-probes).

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

MUNGA/APPMGR.cpp

@@ -12,6 +12,9 @@ void (*gPerFrameHook)() = NULL;
 // an in-process console owns the launch (hosted network races)
 Logical gConsoleMarshalsLaunch = False;
 
+// losing the console mid-mission ends it (lobby-member races)
+Logical gConsoleLossEndsMission = False;
+
 ApplicationManager* ApplicationManager::CurrentAppManager = NULL;
 
 ApplicationManager::ApplicationManager(HINSTANCE hInstance, HWND hWnd, Scalar frame_rate) : Node(ApplicationManagerClassID), runningApplications(this)