docs: finalize documentation to the production state

The project is live in production, so the staged-development scaffolding is removed.

- Delete the staged trackers PLAN.md and PRERELEASE.md.
- Rewrite CLAUDE.md: drop the per-stage workflow; codify the ongoing development
  principles (How we work) and the production model (Branching, CI & production):
  manual prod-deploy / prod-rollback, semver release tags, Ansible provisioning,
  expand-contract migrations.
- De-stage the living docs (README, ARCHITECTURE, TESTING, deploy/ansible, loadtest,
  platform/telegram READMEs) and the docker-compose tuning comments: drop the
  Stage N / R1-R7 / pre-release labels, keep every number and rationale, and fix the
  now-dangling PLAN.md / PRERELEASE.md references to describe the current state.
- Reword stale 'later stage' Go doc comments for subsystems that have shipped.

deploy/ansible/README.md

@@ -1,4 +1,4 @@
-# Prod host provisioning (Stage 18)
+# Prod host provisioning
 
 Idempotent Ansible that prepares the two production hosts. It installs Docker, a
 non-sudo `deploy` service account, SSH hardening, a default-deny firewall,

deploy/ansible/site.yml

@@ -1,5 +1,5 @@
 ---
-# Stage 18 host provisioning. Idempotent: safe to re-run after a host resize.
+# Production host provisioning. Idempotent: safe to re-run after a host resize.
 # Prepares hosts only (docker, hardening, service account, firewall); the
 # application is deployed separately by .gitea/workflows/prod-deploy.yaml.
 

deploy/docker-compose.prod.yml

@@ -3,7 +3,7 @@
 #
 # It (1) publishes caddy 80/443 — there is no host caddy in prod, so the contour caddy
 # owns the edge and does its own ACME on CADDY_SITE_ADDRESS — and the gateway bot-link
-# :9443 the remote bot dials in over mTLS; and (2) retunes the R7 limits down for the
+# :9443 the remote bot dials in over mTLS; and (2) retunes the baseline limits down for the
 # 2 vCPU / 1.9 GiB host (GOMAXPROCS=2, smaller memory caps, shorter Prometheus
 # retention). The contour launches deliberately undersized at zero players; the added
 # node_exporter + Grafana watch host memory so it can be resized at Selectel when
@@ -29,7 +29,7 @@ services:
     ports:
       - "9443:9443"
     environment:
-      # 2 vCPU host: align the Go scheduler with the cgroup quota (R7's 3 needs 3 cores).
+      # 2 vCPU host: align the Go scheduler with the cgroup quota (the baseline's 3-core gateway needs 3 cores).
       GOMAXPROCS: "2"
     deploy:
       resources:

deploy/docker-compose.yml

@@ -25,9 +25,9 @@
 #     backend admin relay reaches the gateway at `gateway:9092` (plaintext).
 name: scrabble
 
-# Bound every container's json-file logs. R7 measured the backend emitting a
-# per-request latency line at info (~14 MiB / 30 min under the 500-player stress
-# peak); without rotation the volume grows unbounded. 10 MiB x 3 files caps each
+# Bound every container's json-file logs. The backend emits a per-request latency
+# line at info (~14 MiB / 30 min under the 500-player peak); without rotation the
+# volume grows unbounded. 10 MiB x 3 files caps each
 # container at 30 MiB. Applied to every service via the *default-logging alias.
 x-logging: &default-logging
   driver: json-file
@@ -52,8 +52,8 @@ services:
       retries: 30
     volumes:
       - postgres-data:/var/lib/postgresql/data
-    # R7 starting limits: 512M leaves headroom over the default 128 MB shared_buffers +
-    # per-connection memory (R2 peaked at 28 backends / 69 MiB RSS); tighten after the run.
+    # 512M leaves headroom over the default 128 MB shared_buffers + per-connection
+    # memory (the load harness peaked at 28 backends / 69 MiB RSS).
     deploy:
       resources:
         limits:
@@ -81,8 +81,8 @@ services:
     environment:
       # search_path=backend matches the migrations (00001 creates the schema).
       BACKEND_POSTGRES_DSN: postgres://${POSTGRES_USER:-scrabble}:${POSTGRES_PASSWORD}@postgres:5432/${POSTGRES_DB:-scrabble}?sslmode=disable&search_path=backend
-      # R7 tuned: the pool sat at its 25-conn cap (28 backends total) at 500 players;
-      # 40 gives headroom for bursts. Postgres (2 cores / 512 MiB) handles it.
+      # The pool caps at 25 conns (~28 backends) around 500 players; 40 gives headroom
+      # for bursts. Postgres (2 cores / 512 MiB) handles it.
       BACKEND_POSTGRES_MAX_OPEN_CONNS: "40"
       BACKEND_HTTP_ADDR: ":8080"
       BACKEND_GRPC_ADDR: ":9090"
@@ -111,8 +111,8 @@ services:
       - dawg-data:/opt/dawg
     # No container healthcheck: the distroless image has no shell/wget. Readiness
     # is covered by the CI post-deploy probe (GET / through caddy).
-    # R7 starting limits (generous over the R2 ~1-core / <=100 MiB peak); tightened to
-    # the agreed prod values after the final stress run. deploy.resources.limits is
+    # Generous over the ~1-core / <=100 MiB measured peak; the prod overlay trims these
+    # to the launch-host values. deploy.resources.limits is
     # honoured by `docker compose up` (Compose v2), not only by swarm.
     deploy:
       resources:
@@ -175,7 +175,7 @@ services:
     # deploy/gen-certs.sh for the test contour; supplied from PROD_ secrets in prod.
     volumes:
       - ${SCRABBLE_CONFIG_DIR:-.}/certs:/certs:ro
-    # R7 tuned: the gateway holds one h2c connection per player, so at 500 players it
+    # The gateway holds one h2c connection per player, so at 500 players it
     # bursts into a 2-core cap (~2.49% transport_error on game.state); 3 cores absorbs
     # the bursts. Per-connection overhead is the realistic prod cost — size for it.
     deploy:
@@ -402,8 +402,8 @@ services:
     volumes:
       - ${SCRABBLE_CONFIG_DIR:-.}/tempo/tempo.yaml:/etc/tempo/tempo.yaml:ro
       - tempo-data:/var/tempo
-    # R7 tuned: tempo reached the 1 GiB cap during the final run (446 MiB in R2);
-    # raised to 2 GiB for headroom against OOM under sustained tracing load.
+    # Tempo reached the 1 GiB cap under sustained load (446 MiB in earlier runs);
+    # raised to 2 GiB for headroom against OOM.
     deploy:
       resources:
         limits: