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

docs/architecture/deployment.md

@@ -15,7 +15,7 @@ The requirements are modest, which is what makes both paths viable:
 | Need | Why |
 | --- | --- |
 | One long-running process | Active games are held in memory ([`overview.md`](overview.md)) |
-| HTTP + WebSocket on one port | Lobby over HTTP, game stream over WebSocket ([`protocol.md`](protocol.md)) |
+| Plain HTTP on one port | Lobby and intents over POST, game stream over SSE — no WebSocket upgrade, which is what keeps this a *plain* HTTP need ([`multiplayer.md`](multiplayer.md) D5) |
 | A writable data directory | The append-only event log ([`lobby-and-sessions.md`](lobby-and-sessions.md)) |
 | Static asset serving | The browser client |
 | No outbound network access | The game talks to nobody |
@@ -59,7 +59,7 @@ network access to that StartOS box. How they get it is the user's configuration
 something the application chooses or should claim.
 
 **One thing the architecture must respect.** A packaged service should not assume it is reachable at
-a fixed, publicly-routable URL. Anything that bakes an origin into the client — absolute WebSocket
+a fixed, publicly-routable URL. Anything that bakes an origin into the client — absolute stream
 URLs, hard-coded hostnames in links, CORS allow-lists pinned to one domain — will break. Serve the
 client from the same origin as the API and use relative URLs throughout. This costs nothing on a
 plain web host and is required on StartOS, so it should simply be the rule.