Two setup screens, not three — the in-game dialog is deleted

Jesse: "it should not go to a separate screen. We should reuse the
Solitaire New Game Screen… in general we should reuse what we already
have."

#newgamedlg was a third copy of the same questions and the one that
drifted: shown only to a solitaire player, it asked "Everyone loses if
COMBINED Revenue…" and explained Employee Rotation in full multiplayer
terms beside a control it had disabled. Both were on the list to
re-word; deleting the screen removes the drift instead of restating it.

New game opens the setup screen IN PLACE rather than navigating, so the
live session stays in memory: the fields open on the rules actually
being played (what the dialog was good for), and Continue Existing Saved
Game puts the board back with no reload. render() calls save() every
frame, so nothing is at risk either way.

The two remaining screens now match below their headers — same three
parameters in the same order, same seed note, same chair note. Solitaire
shows Players at the table locked at 1 rather than omitting it: a fixed
control says "same form, table of one", a missing one made it a
different form sharing a rules block.

Drift guard drops to two prefixes and now fails if any ng- id returns.

Stays in the unshipped v0.7.9. 874 tests pass.

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

CHANGELOG.md

@@ -124,6 +124,36 @@ orientation**, 276 east / 259 west. `setup.ts` is the only place a Mainline node
 rolls the direction from the seed for every grade, so the `?? 'east'` fallbacks in `view.ts` and
 `advance.ts` are unreachable.
 
+### Two setup screens, not three — the in-game dialog is deleted
+
+Jesse, 2026-08-30: "If you are in the Solitaire game and you click the new game dialog, it should not
+go to a separate screen. We should reuse the Solitaire New Game Screen… in general we should reuse
+what we already have."
+
+`#newgamedlg` was a third copy of the same questions and the one that drifted. It was shown ONLY to
+a solitaire player, and it asked "Everyone loses if **combined** Revenue at the end is under" — a
+table's question, put to one person — and explained Employee Rotation in full, in multiplayer terms,
+beside a control it had itself disabled. Both were on the list to re-word. Deleting the screen
+removes the drift instead of restating it, which is the cheaper fix and the one that cannot drift
+again.
+
+**New game now opens the setup screen in place.** Not a navigation: the live session stays in memory,
+so the fields open on the rules actually being played — which is what the dialog was good for, and
+losing "change one dial, redeal, compare" would have been a real loss — and **Continue Existing Saved
+Game** puts the board straight back with no reload and no replay. Nothing is at risk either way:
+`render()` calls `save()` every frame, so the game in progress is always on disk.
+
+**And the two remaining screens now match below their headers.** Each keeps its own opening — the
+lobby's join/secret section and "Create a new game" are multiplayer's alone — but from the parameters
+down they are one form: the same three fields in the same order (seed, players at the table, days),
+the same note about a seed and settings dealing the same railroad, and the same note about every
+chair being taken. Solitaire shows **Players at the table** too, locked at one, rather than omitting
+it — a control that is present and fixed says "this is the same form, at a table of one", where a
+missing one just made it a different form that happened to share a rules block.
+
+The drift guard that had been checking three prefixes now checks two, and a new assertion fails if
+any `ng-` id ever reappears.
+
 ### Three wording and layout fixes
 
 - **The collision entries** on all three screens now read "The game ends immediately and results in