v0.7.8 — the setup screen was unreachable for anyone who had ever played

Third report of the same symptom, this time with the build confirmed
current on screen, which ruled out v0.7.7's caching fault and left the
real cause exposed.

v0.7.5 skipped the setup screen whenever load() found a save, reasoned
as "a saved game is a game to resume". A browser that has ever played
solitaire always has one, so the door could never reach the screen
again — and the fresh private window that appeared to vindicate v0.7.7
simply had no save. Two real faults were stacked; the caching one is
fixed and had been masking this.

The door outranks a saved game now: ?solitaire is a request to set one
up, while a bare reload still resumes (pinned by its own test). Since
Deal clears the save, the screen carries #ss-resume and says what Deal
costs, so the door cannot destroy a game in progress.

Also, per Jesse, riding along rather than taking its own release: the
splash footer now names both ways to play.

868 tests pass, four new. The reproduction was a failing test written
before the fix.

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

TODO.md

@@ -333,6 +333,19 @@ Queued 2026-08-29, from building Gitea#11 and #16 (both shipped in v0.7.3, main
     **The lesson worth keeping: when a fix appears to have had no effect, check that it arrived
     before re-diagnosing it.** A hard-reload would have answered it on the first report.
 
+    **And a THIRD report, 2026-08-30, with the build confirmed current on screen — which is what
+    finally found it. Fixed in v0.7.8.** v0.7.5 skipped the setup screen whenever a save existed
+    ("a saved game is a game to resume"), so any browser that had ever played solitaire could never
+    reach it again; the private window that seemed to vindicate v0.7.7 simply had no save. The door
+    outranks a save now, a bare reload still resumes, and `#ss-resume` keeps the game in progress
+    one button away since Deal clears it.
+
+    **Three attempts, two of them fixing something real that was not the reported fault.** Each was
+    reported as verified, and each verification read what the SERVER served rather than exercising
+    the path with the state a returning player actually has. The thing that worked was a failing
+    test written before the fix. Worth remembering next time a report repeats: reproduce the user's
+    state first, and treat "I verified it" as unearned until something failed the way they described.
+
     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.