v0.8.0.12 — put a player back in their seat after losing their browser storage

Gitea#33. A session token is the only identity the game has, and it lives in
exactly one place the player controls: their browser's localStorage, scoped to
the origin they joined at. Lose it — a cleared profile, a private window, a
different browser — and the seat is unreachable while the game runs on and the
session sits intact on disk. Reported from the table: of two humans in one game
the host reloaded straight back in, the joiner met an empty lobby.

Diagnosed before it was fixed, and two server-side theories of mine were
retracted on the evidence: no storage key changed in 0.8.0.11, nothing in the
app deletes the secret or name, create and join both call persistSession, that
game's sessions.json held both seats, and it resumed with 80 intents replayed.
Both players used the same URL, so it was not a second origin either.

The fix is a recovery link. An administrator mints a code for a named seat
(admin-gated: deciding somebody lost a seat is a judgement no route can make);
the player opens the link and the page trades the code for the token over a
POST, then strips it from the address bar. The link never carries the token —
lobby-and-sessions.md §1 says keep it out of URLs, and a recovery link is
exactly what gets pasted into a chat. Single use, 30-minute expiry, held in
memory because a restart dropping them is the right failure.

server/claims.ts is a pure store, so single use, lazy expiry and one identical
answer for unknown/spent/expired codes are tested rather than asserted. The
admin game listing gained seatedPlayers — the seats a human holds a token for,
read from the session map rather than guessed from player names — so the
StartOS action can offer real players instead of bot chairs.

No rule changed: `git diff v0.8.0.11..v0.8.0.12 -- src/engine/` is empty, so
games in progress resume.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017nnuCv8UodHucFfx3LWEoX

docs/architecture/lobby-and-sessions.md

@@ -36,6 +36,34 @@ and `<ip>:<port>` are both expected — and browser storage is scoped to the ori
 at one address must come back to that address, or they are a stranger with no token. Say so in the
 UI at join time rather than letting someone discover it when they cannot get back in.
 
+**A lost token is recoverable, administratively** (Gitea#33). Everything above makes the token the
+single point of failure: it lives in one browser's storage, and a cleared profile, a private window or
+a different browser ends the seat with the game still running and the session still on disk. Seen at a
+real table — the returning player met an empty lobby while their token sat intact in `sessions.json`,
+and the only way back was an administrator reading the file off the volume and the player pasting it
+into a devtools console.
+
+So there is a supported path, in two halves that are gated differently on purpose:
+
+```
+POST /api/games/<id>/claim  { player }   →  { code, expiresAt, … }   admin secret
+POST /api/claim             { code }     →  { token, gameId, player, gameCode }
+```
+
+**The link carries the code, never the token** — which is the rule three paragraphs up, applied. A
+recovery link is exactly the sort of thing that gets pasted into a chat, so what travels in the URL is
+single-use and expires in thirty minutes (`server/claims.ts`), and the page trades it for the real
+token over a POST as it loads (`?claim=` in `web/main.ts`, which strips it from the address bar either
+way). A leaked code is worthless once spent; a leaked token is the seat for the rest of the game.
+
+**Minting is administrative; spending is not.** Deciding that a particular person has lost a
+particular seat is a judgement no route can make safely — anyone able to mint their own code could
+take any chair at the table. Spending needs no secret because the player following the link is the one
+person in the story who holds none; the code *is* the authorisation, and it is the same shape
+(unguessable, one-time) as the token it hands back. The codes are held in memory: they are minted on
+demand and spent within minutes, so a restart dropping them is the right failure, and persisting them
+would put a credential-equivalent on the volume to solve a problem measured in seconds.
+
 Real accounts can be layered on later without touching the rules engine, which is exactly why
 [`overview.md`](overview.md) keeps that boundary sharp.