v0.7.5 — solitaire asks before it deals, the same way multiplayer already does

A new #solitairesetup screen in play.html asks the full shared game-options
block — type, starting hand, Extra start, revenue, victory conditions,
optional rules — before a genuinely fresh visit deals a game. A saved game,
an explicit ?seed=, or a URL a Deal already wrote all skip past it, same as
?lobby already skips the front doors on an invite link.

The in-game dialog, the lobby and this screen now share one
wireGameTypeBlock()/commitNewGame() pair instead of the dialog carrying its
own copy of the questions.

859 tests pass. Not yet played in a browser.

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

CHANGELOG.md

@@ -19,6 +19,45 @@ page as `v0.1.0 · <sha> · <date>`, so what is deployed can always be identifie
 
 ---
 
+## 0.7.5 — 2026-08-29
+
+### Solitaire asks first, the same way multiplayer already does
+
+Jesse: "let the user choose their options like the start of a multiplayer game"; "asking first is
+the only path." A bare visit to `play.html` used to deal a game on the spot, at whatever defaults
+`gameOptionsFromUrl` fell back to, and the only way to see or change a setting was to open the
+in-game "New game" dialog after the fact — compare a hand you already have, not one you are about
+to be dealt. The lobby has asked this question for every multiplayer game since v0.6.0; solitaire
+never did.
+
+A genuinely fresh visit now lands on a new `#solitairesetup` screen first: game type, starting hand,
+where an Extra may start, the three revenue rates, victory conditions, and the three optional rules
+— then a Deal button. A saved game, an explicit `?seed=`, or a URL a Deal already wrote (`hand` is
+the field every write always sets, so its presence is what tells the difference) all skip straight
+past it, the same way `?lobby` already skips the front doors on an invite link — those are not "no
+plan yet", they are a choice already made, elsewhere.
+
+**One shared block instead of two copies drifting apart.** The in-game dialog, the lobby, and now
+this screen all drive the identical `settings-form.ts` block through one new function,
+`wireGameTypeBlock()` — factored out of what used to be dialog-only code. Only Solitaire can be
+dealt outside the lobby, so the setup screen shows the other four types exactly as the dialog always
+has: present, disabled, with a note pointing at the Multiplayer door. Committing an answer — from
+either the dialog or the setup screen — goes through one `commitNewGame()`, which builds the URL and
+navigates; `start()` is still the only place that turns a URL into a game.
+
+Prefilling is deliberately left to the caller rather than folded into `wireGameTypeBlock` itself:
+the dialog opens on the game CURRENTLY IN PLAY, so redealing to compare keeps comparing against it,
+while the setup screen opens on the plain Solitaire defaults, since there is no live game yet to
+read.
+
+`index.html`'s door copy changed to match: "Start a game" reads "Set up a game" now, and the blurb
+states the floor (15, not "20 Revenue") since that is what a player is agreeing to before they deal.
+
+859 tests pass. **Not yet played in a browser** — verified by `tsc --noEmit`, the full suite, and
+reading the diff, not by loading `play.html` fresh and clicking through it.
+
+---
+
 ## 0.7.4 — 2026-08-29
 
 Three rules issues off the tracker, in the order Jesse asked for them: #13, #5, #19. All three are