0.7.7:0 — bundle Station Master v0.7.7

Submodule pinned to v0.7.7 (af68aac). current.ts bumped in place at
0.7.7:0 — no new version file, no migration: the change is to how the
built client is cached, not to what it does.

Every packaged build until now published ?v=nogit as its cache key (the
.s9pk Dockerfile copies the tree in without .git, so git rev-parse
fails), and serveStatic sent no Cache-Control at all — so 0.7.5's
solitaire setup screen and 0.7.6's fix to it were both installed here
correctly and neither ever reached a browser.

Verified on phoenix.local against what the server actually returns, not
just what was packed: build tag is 0.7.7-mtf7hyxc (not nogit) and the
module graph's inner imports carry the same tag; play.html is no-cache;
a ?v=-tagged module is immutable for a year; an untagged one is
no-cache. Migration 0.7.6:0 -> 0.7.7:0 ran empty and both games in
progress (WHISTLE-4086, COAL-7370) resumed with their same intent counts.

README.md records that a hard reload is NOT a sufficient check for this
class of bug — confirmed in the field on 0.7.6, where only a fresh
private window showed the new build.

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

README.md

@@ -13,12 +13,25 @@ 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.6.** Fixes the solitaire door 0.7.5 introduced: a browser that had ever held a
-multiplayer seat could not reach the new setup screen at all — a bare page load could not tell
-"clicked Play solitaire" apart from "reloaded mid multiplayer game", so the door lost to whatever
-game or lobby that browser last touched. The door now marks its intent explicitly (`?solitaire`), the
-same fix `?lobby` already carries for the door on the other side. Client-side only; every game in
-progress carries over.
+**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
+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
+nothing. `serveStatic` also sent no `Cache-Control` at all, so the pages that carry those tags were
+themselves served from cache. The tag is now the package version plus the build timestamp, and a
+request carrying `?v=` is `immutable` for a year while everything else is `no-cache`.
+
+**Diagnosing "my fix did not ship".** A hard reload is NOT a sufficient check — confirmed in the
+field on 0.7.6: the document refetches but ES module sub-imports keep their cached `?v=` URLs, so the
+module graph stays stale. A fresh private window is the reliable test. Reading what the server
+returns (`curl` inside the container) proves what was installed, never what a browser is running.
+
+**0.7.6 fixed the solitaire door 0.7.5 introduced**: a browser that had ever held a multiplayer seat
+could not reach the new setup screen at all — a bare page load could not tell "clicked Play
+solitaire" apart from "reloaded mid multiplayer game", so the door lost to whatever game or lobby
+that browser last touched. The door marks its intent explicitly now (`?solitaire`), the same fix
+`?lobby` already carries for the door on the other side.
 
 **0.7.5 was a client-side flow change**: a genuinely fresh visit to the solitaire page opens a setup
 screen and asks for the game's options before dealing, the same question the multiplayer lobby has