Fix Access Violation in Multiplayer Lobby when player is removed from the room

[LIFEfreedom]

The Bug: A client would experience an EAccessViolation when receiving a mkPlayersList network message right as they were being removed from the multiplayer room (e.g., kicked by the host or dropped). (my guess)

Root Cause: When a joiner receives the mkPlayersList packet, TKMNetworking.HandleMessagePlayersList updates the local room state and recalculates the client's own index (fMySlotIndex):

fMySlotIndex := fNetRoom.NicknameToLocal(fMyNickname);

If the player's nickname was no longer present in the updated room list, fMySlotIndex was correctly set to -1. However, the code then unconditionally triggered OnPlayersSetup (TKMGamePlayInterface.AlliesOnPlayerSetup).
Inside AlliesOnPlayerSetup, the UI attempts to read properties like gNetworking.MyRoomSlot.VotedYes. Because fMySlotIndex was -1, GetMyRoomSlot returned nil, leading to an immediate Access Violation upon dereferencing the memory offset for VotedYes.

[Kromster80]

If this analysis is true, we should not be processing the mkPlayersList in the first place.