ONLINE LOBBY REPAIR - EVIDENCE AND SCOPE
=======================================

User symptoms: a client joins and can Ready from the host's perspective, but
its own lobby stays stale, launch leaves the host waiting, and the connection
check is inconclusive. Both supplied logs are Playtest 8. They show successful
mod preparation followed by lobby closure/timeout and an exit crash. They do
not show missing/invalid track assets as the reason for this lobby failure.

Confirmed defects in the exact compiled source
----------------------------------------------
1. Party service clears LobbyStatePayload.players, then sets slot only for
   occupied ports. LobbyPlayerPayload.slot defaults to zero. The compiled
   encode_lobby_state rejects player.slot != index even for vacant ports.
   Consequently a normal two- or three-racer lobby encodes an EMPTY Room body.
   The client silently discards it, leaving Ready/settings stale. The Rollback
   probe also cannot negotiate if its client still has unadmitted/default rules.

   Repair: initialize all four slot indices before projecting occupied racers.
   Check serialization before queuing; no empty settings packet is transmitted.
   The client accepts a Room only for its authenticated current roster generation
   and updates current metadata even when only Ready/automatic delay changed.
   Its Ready request waits for that current roster and Rollback configuration.

2. Party service encodes StartPayload with stage=2. The actual compiled encoder
   accepts ONLY 0/1, and the decoder rejects bytes[0]>1. Thus the old Launch
   envelope has an EMPTY body while the host already starts its own guest.

   Repair: stage=1 (committed) on send, require stage=1 on receive, and validate
   encoding before committing a host launch. A remote racer must have completed
   a two-way heartbeat and have recent traffic before host Start is accepted.
   Spectators remain non-blocking and have no controller port.

3. During approval, LinkPeer copies pending.next_sequence before Accepted is
   encrypted. outbound_sequence formerly prefers the still-live PendingRecord
   over the newly promoted LinkPeer. Accepted increments only the old counter;
   the first normal party packet reuses its AEAD key/nonce and is rejected by
   replay protection depending on arrival order.

   Repair: promoted peer sequence takes precedence, exactly like ordinary racer
   promotion. One monotonic nonce domain spans mod admission and party traffic.
   Do not clear/bypass replay windows or weaken authentication. Duplicate
   Accepted retries no longer reset an admitted client's port/phase or replace
   an active match's save identity. No wire layout or protocol stage is invented.

4. The local and both supplied client crash stacks map to:
   RVA 0x119E140 std::_Hash::_Try_emplace (xhash:701)
   RVA 0x11A4CA8 spectators::party_link (party_link.cpp:69)
   RVA 0x12009E9 DirectSession::disconnect
   RVA 0x11D7B9A DirectSession::~DirectSession
   followed by execute_onexit_table. llvm-symbolizer resolves these using the
   matching locally built runtime/PDB. The registry's translation-unit static
   unordered_map has already been destroyed when DirectSession cleans up.

   Repair: process-lifetime registry storage for PartyLink, diagnostic state
   and the lobby's pending-removal mailbox. Normal disconnect still wipes keys,
   joins the network worker and explicitly erases session state. Only the tiny
   empty registry shell is retained until process exit, avoiding destructor-order
   dependence. Class/header layouts, controller leases and guest ABI are intact.

5. UI projection previously changed Failed back to Lobby whenever the retained
   party was stopping. Service could then repeat timeout failures. Repair:
   Failed/Offline remain terminal in receive, service and UI projection until
   an explicit leave/rejoin. No delayed message can resurrect a failed client.

Other evidence / not bypassed
-----------------------------
The second client log initially reports a real Magic Code settings mismatch,
then successfully prepares the host's selection. That consent/compatibility
check is retained. The optional keep-offline identity conflict is also retained:
it protects installed files and is separate from the live session's preparation.
Both client logs show the new runtime running from an older named installation
folder. Ship/use a complete fresh package, not a mixture of helper executables.

Composition and validation
--------------------------
New final Patch Pipeline overlay after rollback-connection. Five first-party
translation units plus the UI context include are externally staged; checked-out
submodules, RecompiledFuncs and RecompiledPatches are not edited. No simulation,
renderer, graphics/LOD settings, save data or mod package is changed. Existing
lobby layout, invitations, spectators, player swaps and diagnostics are retained.

Recovery snapshot: D:/DiddykongWorkFolder/lobby-link-repair-20261023/baseline
The 2,265-file baseline includes three untracked lobby-discovery planning files
being updated concurrently outside this task. Those are left intact and their
before/current hashes recorded separately (and only if their untracked status
is present in the baseline). All other pre-existing files must remain byte-for-
byte identical. The audit re-composes exact staged outputs and compiler bindings,
reruns retained source-contract audits and compares them with Playtest 8.
It checks repairs against the actual compiled codec validators and inspects
linked feature/version markers plus allowlisted Windows ZIP/Linux AppImage.

No game, mod, test executable or AppImage is launched. Live network/gameplay
acceptance remains the user's work. No Git push, publication or update signing.
