v0.5.2 — the splash's multiplayer door opens, and knows whether it should

The "Play multiplayer" door on index.html had sat disabled, labelled
"Coming soon", since before the server existed — Phases 2 through 4 built
a working lobby and nothing ever linked to it. Loading the site landed on
the same solitaire splash whether a real multiplayer server was behind it
or not, with no visible way in. Found packaging Phase 6 for StartOS.

The door is now a live link to ./play.html?lobby, and main.ts's start()
routes ?lobby straight to the lobby screen — the same showScreen('lobby');
runLobby(beginRemote) the in-game Multiplayer button already used —
instead of dealing a solitaire game first.

GET /api/health is new, and exists to be failed. The same dist/ ships both
served by src/server/ and uploaded as flat files by deploy-web.ts, and the
bundle is identical either way (D4), so the page cannot know from its own
build which it is; every other route 404s an unknown path exactly as a
static host does, so nothing distinguished them. The splash probes it on
load and closes the door when nothing names itself in reply.

The door starts open and only ever closes, deliberately: a wrong "no
server" is the bug above again — invisible, and it strands a player who
does have one — while a wrong "there is one" costs a click and a lobby
that says it cannot connect. The reply must name itself rather than merely
return 200, or a host answering every path with its index page would pass.

Verified: tsc clean; 659 tests pass (656 + 3); /api/health exercised live
against a running server — 200 with the right body, unauthenticated, while
an unknown path and a wrong method both still 404, which is what makes the
probe discriminate at all.

The probe's own test was vacuous on the first attempt — both its "closes"
cases reached close() through the .catch arm, so deleting the body-naming
check outright still passed. Caught by mutating splash.ts and re-running;
the test now covers all three closing routes and fails without the check.

CHANGELOG.md

@@ -19,6 +19,48 @@ page as `v0.1.0 · <sha> · <date>`, so what is deployed can always be identifie
 
 ---
 
+## 0.5.2 — 2026-08-21
+
+Found packaging Phase 6 for StartOS: the splash's "Play multiplayer" door had sat `disabled`,
+labelled "Coming soon," since before the server existed — Phases 2 through 4 built a working
+lobby and nobody ever pointed a link at it. Loading the site landed on the exact same solitaire
+splash whether a real multiplayer server was behind it or not, with no visible way in.
+
+`index.html`'s door is now a real link to `./play.html?lobby`, matching the other two doors.
+`main.ts`'s `start()` checks for `?lobby` and routes straight into the lobby screen — the same
+`showScreen('lobby'); runLobby(beginRemote)` the in-game Multiplayer button already used — instead
+of dealing a solitaire game first and leaving the player to find that button themselves.
+
+### The page can now tell whether a server is behind it
+
+The same `dist/` ships two ways — served by `src/server/`, or uploaded as flat files by
+`scripts/deploy-web.ts` with no server at all — and the bundle is byte-identical in both, because
+there is one client and the mode is decided at runtime (D4). So the splash could not know from its
+own build which it was, and nothing else distinguished them either: every route in `http.ts`
+answers a 404 for a path it does not have, exactly as a static host does.
+
+`GET /api/health` is new, and exists to be failed: `{ ok, service, engineVersion }`, no
+authentication (it says only that a Station Master server is answering, which is what the door is
+about to offer anyway — no game, no seat). The splash probes it on load and closes the door when
+nothing names itself in reply.
+
+**The door starts open and only ever closes**, deliberately. A wrong "no server here" is the bug
+above all over again — invisible, and it strands a player who *does* have a server. A wrong "there
+is one" costs a click and a lobby that says it cannot reach a server, which is legible and
+recoverable. So a slow or flaky probe leaves the door alone; only a definite answer closes it. The
+reply has to name itself rather than merely return 200, since a host that answers every path with
+its own index page would otherwise pass.
+
+Bug fix: the lobby machinery was already complete and tested (Phase 4, v0.5.1); this only
+re-enables the door to it, and teaches the splash when to.
+
+Worth recording about the tests: the first version of the probe's test passed with the naming
+check deleted outright. Both of its "door closes" cases happened to reach `close()` through the
+`.catch` arm, so the branch that actually reads the body was never run — and the comment claimed
+otherwise. Caught by mutating `splash.ts` and re-running rather than by reading it.
+
+---
+
 ## 0.5.1 — 2026-08-21
 
 Multiplayer Phase 4 — lobby, sessions, reconnection (`docs/architecture/multiplayer.md` §12 steps