ops: restore an automated phone-accessible deployment path for SAGE

[ninthworld]

Parent: #713. Follow-up to #424.

Problem

The first product milestone is that two people click a link and play in a browser, but current main documents only local execution and contains no shipping deployment assets or workflow. The earlier GitHub Pages + Unraid issue is closed, yet the current repository has no Dockerfile, Pages deployment, GHCR publish workflow, WSS endpoint configuration, or operator runbook.

Goal

Provide one supported, repeatable path that deploys the current SAGE client and server and can be tested from a phone after changes land on main.

Scope

• Static production client hosting with a configurable secure WebSocket endpoint.
• Minimal non-root server container, pinned/reproducible build, and health check.
• CI publication only after required verification gates pass.
• Unraid deployment/update/rollback documentation, unless a different target is explicitly chosen.
• HTTPS/WSS exposure that does not expose the Unraid administration surface.
• Document in-memory room/game loss on server restart.
• Add basic logs and operational checks sufficient to tell whether client, socket, and server are healthy.

Acceptance criteria

• A successful main build produces a deployable static client and versioned server image.
• The client connects through wss:// without source edits.
• The container runs non-root and exposes a usable health check.
• A commit-SHA image can be deployed and rolled back.
• Update and restart behavior is documented.
• The complete lobby-to-game path is manually verified from a phone.
• Secrets and private network details are not committed.
• Deployment failure cannot bypass the existing test gates.

Non-goals

• Android APK or app-store distribution.
• Persistence across server restarts.
• Public matchmaking/account infrastructure.

[ninthworld]

Deferred, not rejected — closing so the active queue reflects what the project is actually ready for.

Why now. Deployment buys reach, and reach is only worth paying for once the thing being reached is worth playing. The merge criterion here has always been playing, and by that standard the engine is where the work still is: the catalog is 253 cards, whole mechanical families remain named in exclusions.json rather than built, and the one judgment automated coverage cannot make — whether a game of this is good — has not been made yet by anyone with a phone or without one. A deployment path built now would be maintained through every change that follows it, and would be answering a question nobody is asking.

What this costs while it stays closed. Playtesting stays local: make e2e-smoke against a real server, sage-cli as the protocol-independent surface, and a browser on the same machine. Nothing in the current gates depends on a deployed target, so nothing rots in the meantime.

What would make it worth reopening, roughly in order:

1. Someone other than the maintainer needs to play it — that is the moment a link beats a checkout, and it is the real trigger.
2. A game is judged fun enough to want a second one. Until then the work being validated is the engine's, and local play validates it faster.
3. The room model outlives a restart, or its not doing so is explicitly acceptable to the people playing. Today an in-memory room means every deploy ends every game, which is a poor first impression to ship deliberately.

The scope in this issue does not need rewriting when that happens — the acceptance criteria are still the right ones, and #424's history is still the relevant background. Reopen rather than re-file.