docs: align transport architecture with control plane

docs/TECH_STACK.md

@@ -180,18 +180,20 @@ Python, no .NET, no network." Keeping the shipped game GDScript-only (no
   "C# backend" in `README.md`'s early framing was never built. A backend
   service *is* now planned for matchmaking (see below), but nothing has
   chosen C# for it — that framing predates every real decision here.
-- **No HTTP/WebSocket/gRPC layer** for multiplayer — ENet/Steam SDR over UDP
-  only, via Godot's own `MultiplayerAPI`. Matchmaking will add the project's
-  first non-UDP network path, for backend traffic only; the simulation stays
-  on ENet/SDR.
+- **No HTTP/WebSocket/gRPC layer for simulation traffic** — the live game uses
+  ENet/Steam SDR over UDP via Godot's own `MultiplayerAPI`. The matchmaking
+  control plane now has an authenticated Go REST/WebSocket boundary for queue,
+  proposal, assignment and recovery traffic; simulation remains on ENet/SDR.
 - **No ONNX or other ML runtime in the shipped game** — see "AI opponents"
   above.
 
 ## Planned, not yet built
 
-- **A Go matchmaking control plane** — independently runnable API, matcher,
-  allocator and maintenance roles backed by PostgreSQL and Redis, deployed on
-  provider-portable Kubernetes with Agones-managed game fleets. The cloud
-  provider remains deliberately replaceable; the application stack is locked.
+- **The remaining Go matchmaking control-plane deployment** — independently
+  runnable matcher, allocator and maintenance roles backed by PostgreSQL and
+  Redis, deployed on provider-portable Kubernetes with Agones-managed game
+  fleets. The authenticated API boundary exists; durable production wiring and
+  provider deployment remain. The cloud provider remains deliberately
+  replaceable; the application stack is locked.
   This is a 1.0 launch blocker and the single largest departure from "one
   Godot project, no backend". See [`MATCHMAKING.md`](MATCHMAKING.md).