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>

RP/VTV.cpp

@@ -179,6 +179,16 @@ void
 			Check(host);
 			Mover
 				*mover = (Mover*)host->GetEntityPointer(message->inflictingEntity);
+			if (mover == NULL)
+			{
+				//
+				// The inflicting entity is gone - its pod left the race
+				// mid-mission (consumer multiplayer; arcade pods never
+				// left). Nothing to bounce against.
+				//
+				Check_Fpu();
+				return;
+			}
 			Verify(mover->IsDerivedFrom(Mover::GetClassDerivations()));
 			Vector3D
 				v;