v0.7.6 — the solitaire door could not reach solitaire

Found by Jesse playing v0.7.5 on phoenix.local: a browser that had ever
held a multiplayer seat could not reach the new solitaire setup screen
at all. start() checked a browser-remembered multiplayer session before
ever looking at solitaire's own state, and a bare ./play.html load could
not tell "clicked Play solitaire" apart from "reloaded mid multiplayer
game" — the same problem ?lobby already solved for the door on the
other side, never applied to this one.

The door now links to ./play.html?solitaire, and start() treats that,
an explicit ?seed=, or the setup screen's own ?hand= (written by every
Deal) as proof this navigation means solitaire — checked ahead of the
remembered-session lookup rather than only below it.

862 tests pass, three new.

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

TODO.md

@@ -315,9 +315,18 @@ Queued 2026-08-29, from building Gitea#11 and #16 (both shipped in v0.7.3, main
     rules — before a genuinely fresh visit deals anything; a saved game, an explicit `?seed=`, or a
     URL a Deal already wrote all skip past it. The in-game dialog, the lobby and this screen now
     share one `wireGameTypeBlock()`/`commitNewGame()` pair instead of the dialog carrying its own
-    copy. Reasoning in `CHANGELOG.md`. **Committed but not yet played in a browser** — verified by
-    `tsc --noEmit` and the full suite (859 pass), not by loading the page and clicking through it.
-    Worth being an early item in the next play session, alongside #39's four unplayed v0.7.4 features.
+    copy. Reasoning in `CHANGELOG.md`.
+
+    **Played in a browser on `phoenix.local` 2026-08-29, and it found a real bug — fixed same day in
+    v0.7.6.** The splash's "Play solitaire" door landed straight in a leftover Co-op four-seat lobby
+    instead of the new setup screen: `start()` checked a browser-remembered multiplayer session
+    before ever looking at solitaire's own state, and a bare `./play.html` load could not tell "I
+    clicked Play solitaire" apart from "I reloaded mid multiplayer game" — the same class of problem
+    `?lobby` already solved for the door on the other side (D11), just never applied to this one. The
+    door now marks its intent (`?solitaire`), checked ahead of the remembered-session lookup. Still
+    not verified past that: nobody has clicked all the way through the setup screen's own fields and
+    confirmed the dealt game matches what was chosen. Worth being an early item in the next play
+    session, alongside #39's four unplayed v0.7.4 features.
 
 ---