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

CHANGELOG.md

@@ -19,6 +19,32 @@ page as `v0.1.0 · <sha> · <date>`, so what is deployed can always be identifie
 
 ---
 
+## 0.7.6 — 2026-08-29
+
+### The solitaire door could not reach solitaire
+
+Found by Jesse verifying v0.7.5 on `phoenix.local`: from a browser that had ever held a multiplayer
+seat, clicking **Play solitaire** on the splash landed straight in a Co-op, four-seat lobby left over
+from unrelated earlier testing — not the new setup screen v0.7.5 just shipped.
+
+`start()` checks a browser-remembered multiplayer session (`station-master.remote.v1`) before it ever
+looks at solitaire's own state, and there was nothing distinguishing "clicked Play solitaire" from
+"reloaded mid multiplayer game" — a bare `./play.html` load means both. `?lobby` already solved the
+identical problem for the door on the other side (D11); the solitaire door had no equivalent marker.
+
+The door now links to `./play.html?solitaire`, and `start()` treats that — along with an explicit
+`?seed=` or a `?hand=` the setup screen's own Deal button just wrote — as unambiguous proof this
+navigation means solitaire, checked ahead of the remembered-session lookup rather than only below it.
+The `hand` check matters on its own: without it, pressing Deal would work once and then bounce the
+very next load into the remembered game, since `commitNewGame`'s URL carries `hand=` but not
+`solitaire=`.
+
+862 tests pass, three of them new: the door reaching solitaire past a remembered game, a bare reload
+still correctly resuming one (unchanged behaviour, pinned so the fix does not overreach), and Deal's
+own URL surviving the same bounce.
+
+---
+
 ## 0.7.5 — 2026-08-29
 
 ### Solitaire asks first, the same way multiplayer already does