0.7.8:0 — bundle Station Master v0.7.8

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

README.md

@@ -13,8 +13,22 @@ Station Master is a railroad operations board game with an authoritative multipl
 solitaire needs no server and is not what this package is for. This package runs that server —
 the browser client, the lobby, and the intent/SSE API — as a single StartOS service.
 
-**Bundled version: 0.7.7.** Fixes the client caching that stopped the two releases before it from
-ever reaching a browser. `build-web.ts` stamps a build tag onto every module URL as a cache key, and
+**Bundled version: 0.7.8.** Makes the solitaire setup screen reachable at all. 0.7.5 skipped it
+whenever `load()` found a saved game — reasoned as "a saved game is a game to resume" — and a browser
+that has ever played solitaire always has one, so the door could never reach the screen again. The
+door (`?solitaire`) outranks a save now; a bare reload still resumes. Since dealing calls
+`clearSave()`, the screen carries a **Continue saved game** button and states what Deal costs, so the
+door cannot destroy a game in progress. A solitaire save is browser-side, so nothing on this server
+is involved either way. The splash footer also now names both ways to play.
+
+**This was reported three times before it was found, and the first two fixes were real bugs that were
+not it** — a routing fault (0.7.6) and a caching fault (0.7.7). Both were reported as verified, and
+both verifications read what the SERVER returned rather than exercising the path with the state a
+returning player actually has. What found it was a failing test written before the fix. Worth knowing
+when the next "that didn't work" arrives: reproduce the reporter's state first.
+
+**0.7.7 fixed the client caching** that stopped the two releases before it from ever reaching a
+browser. `build-web.ts` stamps a build tag onto every module URL as a cache key, and
 its fallback when `git rev-parse` fails was the literal `nogit` — which is precisely the `.s9pk`
 case, since the Dockerfile copies the working tree in without `.git`. So every packaged release
 published `./web/main.js?v=nogit`, byte-identical to the one before, and a returning browser refetched