feat(lobby): block create/join while in matchmaking

[ChronoFinale]

While a matchmaking search is active, you could still create or join a custom lobby and end up searching and in a lobby at the same time. With this PR, a queued player who tries either gets a "Leave Queue & Continue" overlay instead; continuing leaves the queue and then re-runs the action. When not searching, nothing changes.

The bug

create_lobby_with_gamemode (ui/main_menu/create_lobby.lua) and SPDRN._join_lobby_with_code (ui/main_menu/join.lua) never checked matchmaking state.

The fix

Both entry points now open with a guard — join's:

if MPAPI.matchmaking.guard_queued(function() return SPDRN._join_lobby_with_code(code) end) then
	return
end

(create's is identical, replaying create_lobby_with_gamemode(key).) When not searching, guard_queued returns false and the function proceeds as before. When searching, it shows the overlay and stashes the closure to run after leaving the queue. If the player declines, the entry point has already returned; nothing happens.

The closure re-enters the mod's own entry point, not MPAPI.create_lobby/MPAPI.join_lobby. That is the load-bearing detail: these entry points call SPDRN.setup_lobby_events, which wires the lobby events and the connected handler that moves the client into the lobby. Replaying only the API call would create/join server-side (the host sees you) while your client stays stranded on the main menu.

How to review

• The product change is two near-identical small guards: ui/main_menu/create_lobby.lua and ui/main_menu/join.lua. Start there.
• The rest of the diff is the new test. Its header explains the stranding failure mode; the control case at the bottom reproduces it.

Tests

From the repo root:

luajit tests/lobby_guard_while_queued.lua

Covers:

• create and join are blocked while searching (no lobby allocated, overlay shown, replay stashed)
• the replay runs the full flow, including setup_lobby_events, for both create and join
• join proceeds unchanged when not searching (create's replay exercises the same not-searching path)
• a control case replays the API primitive directly and asserts setup_lobby_events never runs, pinning the stranding failure mode

Depends on

Both must merge before this PR:

• feat(matchmaking): queue guard for run start + reusable guard_queued helper BalatroMultiplayerAPI#7 adds MPAPI.matchmaking.guard_queued and the overlay. The guards call it unconditionally, so the installed API must include it.
• fix(networking): FIFO-queue api_client responses so concurrent requests don't collide BalatroMultiplayerAPI#10 fixes api_client's single pending-callback slot. "Leave Queue & Continue" sends the leave-queue request and then this create/join while the leave response is still in flight; without the FIFO fix the second request overwrites the first's response handler and the create/join silently fails.

Related: Balatro-Multiplayer/BalatroMultiplayer#496 adds the same guard to the PvP mod, so behavior is consistent across mods.

What it looks like

Clicking a lobby create/join button while searching shows the shared guard overlay (from the API's queue-guard PR) instead of silently stranding the queue — with the search visibly running in the status panel:

Full annotated gallery of the guard's behavior (every entry point, every button outcome): VERIFICATION.md