v0.5.0 — multiplayer Phases 2 and 3: a server that runs a game and survives being restarted

Phases 0-1 shipped in v0.4.0 (seat/identity split, per-player turn state, the Session boundary).
This lands Phase 2 (server core, one game, no lobby) and Phase 3 (persistence and resumption) per
docs/architecture/multiplayer.md §12. Phases 4-6 (lobby/reconnection, the 22 opponent-directed
cards, StartOS packaging) are still ahead.

Phase 2: src/server/session.ts hosts a game in pure logic (no sockets) on top of game.ts's existing
Game/submit/currentActor/actionMenu; it verifies seat === currentActor(game) itself before calling
submit, since submit() trusts its caller and a server can't. src/server/http.ts and index.ts add
POST /api/game, GET /api/stream (SSE, per-seat), POST /api/intent, and static serving of dist/.
src/sim/frame-delta.ts is a purpose-built per-seat board delta for one live push at a time. Found
and fixed along the way: actionMenu(game, seat) only used seat for the hand field, so a server
computing every connected seat's Menu would have handed the acting player's legal moves to a
waiting seat. Verified with a live end-to-end smoke test (2-player game, two SSE streams, a
rejected intent from the wrong seat, an idempotent resend) plus test/server/session.test.ts and
test/redaction.test.ts. Not verified: an actual browser (none available in this environment).

Phase 3: src/server/persistence.ts writes game.json and turn-timings.json, atomic-rewrite-then-
rename. game.ts gained fromMultiplayerSave, fixing a narration-attribution bug found while testing
it (fromSave's replay loop drops the actor argument, invisible in solitaire, unreadable the moment
there's more than one seat — fromSave itself still has this gap, deliberately untouched). Verified
live: server killed and restarted mid-game, both seats reconnected exactly where they left off.

Two rules bugs found while building this: the New Train phase never implemented its car-placement
round (every car of every train was placed by the Superintendent alone, in every mode, all along —
now reads the round position off tray.consist.length); and victory conditions are now one shared,
configurable GameConfig set across solitaire/competitive/coop instead of a fixed length lookup and
a dead firstToTarget condition.

Also folds in the three fixes already released on the patch line as v0.4.9b/c/d: a switching
train's crew badge failing to draw once it left the Office square, an unload that always took the
westmost car regardless of which was picked, and a legal decision that could render with zero
buttons.

docs/testing/0.5.0-test-plan.md and three reported-bug save files (docs/station-master-seed*.json)
included for reproducibility. tools/jitsi-harness/ deliberately left untracked — unrelated
side-project work, not part of this release. 635 tests, 0 failures.

docs/rules/implications.md

@@ -82,10 +82,12 @@ direction. `DivisionNode.gradeUp` records the direction a train travels when **c
 going the other way is descending. Brakeman and Airbrakes apply to the descent, Helpers to the
 climb, so turning the card around swaps which trains each card helps.
 
-One gap remains, and it is a **setup** gap rather than a rules one: `createGame` is synchronous and
-returns a ready state, so there is no point at which a player can be asked. Orientation is currently
-**rolled** — deterministic from the seed, and roughly even (51/49 east/west across 400 games) — and
-should become a real player choice when setup gains an interactive phase.
+**Settled (v0.5.0): orientation is never a player choice, and this overrides the card's own printed
+"Player sets orientation."** A Heavy Grade sits on the shared west-to-east Division chain, between
+two players (§4.2) or beyond an end Division Point next to one — never inside a single player's own
+district — so whichever direction climbs advantages one neighbour over the other, and no one player
+has a fair claim to the decision. Orientation is **rolled** from the seed instead — deterministic,
+and roughly even (51/49 east/west across 400 games) — identically for solitaire and multiplayer.
 
 **Still not implemented**: the Action (10) and Space-use (12) cards, which are genuinely
 multiplayer-only. Playing them is rejected with `NOT_IMPLEMENTED`.