Finalize EOS multiplayer with live gameplay and crash acceptance

[corepunch]

Battle.net now has automated acceptance for complete EOS guest multiplayer: separate installations discover and join a server-authored lobby, launch a real WC3 fixture map, issue Move/camera commands and receive continuing shared-world snapshots. Default connectivity and forced relay use the production client, server, game module and renderer.

The remaining lifecycle gap was guest departure: EOS cleared partial packets, but the server retained the client and occupied lobby slot. Permanent peer closure now enters the normal server drop/zombie lifecycle, reopens the lobby slot and preserves the host and other peers. Guest-side host loss clears room/connection/fragment state and returns through the existing menu recovery path. Asynchronous departure failures remain visible.

Changes:

• Trusted same-repository PR/main CI fetches the pinned private SDK and restricted GitHub player credentials; fork CI keeps the SDK-free suite.
• Eight bounded live scenarios cover login/publication/reconnect, maximum-size packet exchange, default/forced-relay gameplay, graceful leave, and host/guest process crashes without SDK teardown.
• Gameplay checks validate lobby slots/names/races/teams/colors/chat, incompatible discovery/map admission, full-room filtering, real loading/sign-on, both players' unit movement and 100 fresh monotonic snapshots. Crashes must prove client menu recovery or host survival and reusable server/lobby slots.
• Lobby chat now uses each client's authoritative sanitized name, matching the name shown in its slot; the server command regression verifies both recipients and sender ownership.
• A generated two-player map and Mesa offscreen rendering make these checks independent of retail assets. Expanding the fixtures also fixes mpqtool pack silently truncating inputs beyond 128 files.
• Release builds run offline EOS regressions in isolated output directories; test modules remain outside shipped archives. Documentation records the diagnostic commands and coverage limits.

Validation:

• Full macOS arm64 make EOS=1 TEST_JOBS=4 test and make EOS=0 TEST_JOBS=4 test passed.
• Offline EOS lifecycle suite: 81/81 assertions in seven tests. The new guest-loss regression reproduced four failures before the fix.
• Bounded real local client/server map test passed both Move/camera command round-trips and 100 fresh snapshots.
• The local diagnostic also passes menu recovery and idle frames after graceful host shutdown; it reproduced an invalid post-shutdown server tick before the driver was aligned with the normal engine loop.
• Workflow YAML syntax and git diff --check passed.
• GitHub CI passed all checks on c6f02079ec9b8de0d7a055b74387592aedce2e21: all eight live scenarios passed, including default/forced-relay real gameplay and both process-crash directions. Each gameplay pair verified 100 fresh snapshots and both players' Move/camera commands.
• Graceful gameplay host loss returned the guest to the menu in 113 ms (direct) / 107 ms (relay). Forced-relay host-crash menu recovery took 10,105 ms; guest-crash server/lobby reclamation took 13,819 ms while host snapshots continued.

The fixture run validates gameplay and UI lifecycle; retail artwork, long matches and every cross-platform hardware/NAT combination remain broader compatibility testing.

Protocol impact: no network wire-format or save-format changes.