Submodule pinned to v0.7.8 (193800a). current.ts bumped in place at
0.7.8:0 — no new version file, no migration: the change is which screen
a solitaire visit lands on, plus the splash footer's wording. Both are
client-side, and a solitaire save lives in the browser rather than on
this server, so nothing here is involved either way.
0.7.5 skipped the setup screen whenever the browser held a save, and any
browser that has ever played solitaire holds one — so the door could
never reach the screen again. The door outranks a save now; a bare
reload still resumes; #ss-resume keeps the game in progress reachable
since Deal clears it.
Verified on phoenix.local against what the server returns: the door
carries ?solitaire, play.html carries #ss-resume and #ss-saved-note, the
footer names both ways to play, and the build tag is 0.7.8-mtfaojtv.
Migration 0.7.7:0 -> 0.7.8:0 ran empty and both multiplayer games in
progress (WHISTLE-4086, COAL-7370) resumed with their same intent counts.
The behaviour itself is covered by four new tests upstream that
reproduce the reported state (door + existing save) rather than by
reading served output — which is what the two previous attempts did, and
why they were reported as verified while still being wrong.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AdG46Ja2PEDBkpqiDazMoX
