Refuse websocket upgrades with HTTP statuses, not close codes

A close() before accept() carries the HTTP status of the refused
upgrade, not a WebSocket close code: RSGI (granian) uses the value
verbatim as the response status, so 4401 panicked on the invalid status
(InvalidStatusCode) and — granian being built with panic = "abort" —
aborted the worker and took the whole app down. ASGI servers answer 403
regardless, and browsers report a refused handshake as an abnormal close
(1006), so the 4401/4403/4404 codes never reached clients anyway.

Reject 401/404/403 to mirror GET /api/games/{id}, and classify a failed
first connection in the game page through the REST API so players still
see "session expired" / "game no longer available" instead of a retry
loop. Add a regression test asserting every pre-accept rejection uses a
status in the HTTP range.

server/README.md

@@ -233,8 +233,11 @@ All endpoints except `/api/health`, `/api/docs`, `/api/openapi.json`,
 ## WebSocket protocol
 
 Connect to `/ws/games/{game_id}` with your session cookie. Only seated
-players are accepted; unauthenticated, unknown-game and non-player
-connections are closed with codes `4401`, `4404` and `4403` respectively.
+players are accepted; the upgrade is refused before the handshake
+completes with an HTTP status mirroring `GET /api/games/{id}`: `401`
+unauthenticated, `404` unknown game, `403` not seated. (Browsers report
+a refused handshake as an abnormal close — there is no close code to
+read.)
 
 Server → client messages are JSON objects with a `type`: