v0.4.0 — multiplayer Phases 0 and 1: seat and player split apart, turn state per player, the page behind a Session, and eight seat/player mix-ups fixed with tests that fail without them

README.md

@@ -10,7 +10,7 @@ train into an occupied Subdivision. Get that wrong and two trains meet at speed.
 
 ## Status
 
-**v0.3.1 — solitaire is playable in a browser.** The whole game runs client-side: the engine is pure,
+**v0.4.0 — solitaire is playable in a browser.** The whole game runs client-side: the engine is pure,
 imports nothing outside itself, and never touches `Math.random`, so a static host is all it needs.
 
 - **Rules** — fully specified. Ten gaps in the original prototype rules found and resolved.
@@ -18,9 +18,10 @@ imports nothing outside itself, and never touches `Math.random`, so a static hos
 - **Architecture** — six documents, including a 20-component build plan.
 - **Code** — the engine, the bot, the balance harness, the replay viewer and the playable page. A
   game can be saved, shared, replayed and stepped back through.
-- **Not built** — multiplayer (the engine runs 2–5 player games and the bot plays them, but there is
-  no server, no turn submission and no per-player view), the 22 opponent-directed cards, and real
-  audio.
+- **Not built** — the multiplayer server (Phases 0 and 1 of the plan are done: seat and player are
+  separate, turn state is per player, and the page talks to a `Session` rather than to the engine, so
+  a remote one drops in without the page changing — but there is no server, no turn submission and no
+  per-player push), the 22 opponent-directed cards, and real audio.
 
 Balance is *not* where it should be: the developer bot averages 7.0 Revenue against a target of 20 —
 of which ~5.4 is the "one Revenue per train that clears your section" rule, so the working freight