castle/golf: play again then back to the room seats you at the table you declined

[aaylward]

Found by review on #308; not fixed there.

What happens

At an ended table, click Play again, then Back to the room before the new table arrives:

1. Play again sends createGame. Nothing on screen changes until the hub answers.
2. Back to the room runs leaveTable, which on an ended view is purely local — clear() and onLeft(), no frame sent (useCastleTable.ts). The table closes, the URL returns to the room.
3. The gameJoined for the create then lands, and useLobby.handleGame navigates to the new table.

You end up seated at a table you just declined, and have to click Leave table to get out of it. The window is one round trip, so it takes a deliberate quick second click — but that second click is exactly the "no, wait" reflex.

Golf has the same shape: its Play Again is createTable with no in-flight state, and its Leave is available beside it.

Why it wasn't fixed

The create cannot be recalled — by the time the player changes their mind the hub has already made the table and seated them. Every fix is a real design choice rather than a one-liner:

• Take the exit away while the create is in flight. Cheapest, and castle: the ending arrives in front, with a way to play again #308 already tracks the in-flight table for the play-again button (opening). But a create that comes back refused — storage unavailable, say — would leave the player looking at a dialog with no way out.
• Leave the new table on arrival. A create marked as abandoned sends leaveGame when its gameJoined lands. Correct, and it costs a small state machine plus a flash of the new table.
• Leave that fixed. One extra click, in a window a player has to work to hit.

I would take the second if it is worth anything at all, and the third otherwise — but it is a judgment call about how much the flash costs, which is why it is here rather than in the PR.