docs(multiplayer): consolidate tracking into one document

multiplayer-todo.md and multiplayer-next.md tracked overlapping
information in two places. Fold everything into multiplayer-next.md
(architecture decisions, wire format, task breakdown with checkboxes,
gotchas list, testing notes) and delete multiplayer-todo.md. Section
numbers are unchanged, so existing code comments citing them by
section/task number still resolve; update every such reference to
point at the new filename.

docs/MATCHMAKING.md

@@ -1,9 +1,9 @@
 # Matchmaking — casual and ranked queues
 
 Architecture and locked product policy for Phase 8. This is a **1.0 launch
-blocker**. The numbered, independently implementable tasks and their
-acceptance criteria live in [`multiplayer-todo.md`](../multiplayer-todo.md);
-the short live checklist is [`multiplayer-next.md`](../multiplayer-next.md).
+blocker**. The numbered, independently implementable tasks, their acceptance
+criteria, and current progress all live in
+[`multiplayer-next.md`](../multiplayer-next.md).
 
 Nothing in Phase 8 is implemented yet. This document records the decisions
 those tasks assume so an implementer does not have to redesign the system

docs/TECH_STACK.md

@@ -56,7 +56,7 @@ snapshot/restore API. That fact is why the multiplayer architecture is
 server-authoritative with client-side prediction of only the local ship,
 rather than rollback/resimulation netcode — rollback would require
 deterministic replay, which no physics engine choice here provides
-(`multiplayer-todo.md` §1, decision 1).
+(`multiplayer-next.md` §1, decision 1).
 
 ## Multiplayer transport: Godot's built-in `MultiplayerAPI` over ENet
 
@@ -71,7 +71,7 @@ Design choices layered on top of the built-in peer, and why:
 - **`ENetMultiplayerPeer.server_relay` is forced to `false`.** It defaults
   to `true`, which lets any client `rpc()` any other client *through the
   server* — incompatible with a server-authoritative model. Called out in
-  `multiplayer-todo.md` §2.1 as "the single highest-value one-line security
+  `multiplayer-next.md` §2.1 as "the single highest-value one-line security
   change in the document."
 - **Manual multiplayer polling**, not Godot's automatic idle-frame poll.
   `NetworkManager` calls `set_multiplayer_poll_enabled(false)` because the
@@ -84,7 +84,7 @@ Design choices layered on top of the built-in peer, and why:
 - **A custom binary wire format** (`net_codec.gd`) rather than raw RPC
   argument marshalling, for compact, quantised input/snapshot packets sent
   at high frequency — no stated alternative was considered in the docs, but
-  the packet-size/channel-intent design in `multiplayer-todo.md` §2 is
+  the packet-size/channel-intent design in `multiplayer-next.md` §2 is
   extensive and deliberate.
 
 ## Optional multiplayer transport: Steam (GodotSteam)
@@ -96,7 +96,7 @@ Relay), from a custom GodotSteam-patched Godot build (not stock Godot —
 use ENet only, and a build without the `steam` feature is fully functional
 without it.
 
-**Why it's optional and why raw ENet remains primary:** `multiplayer-todo.md`
+**Why it's optional and why raw ENet remains primary:** `multiplayer-next.md`
 states plainly that "Docker/VPS is the primary v1 deployment path. Raw ENet
 self-hosting needs port forwarding, and SDR is Phase 7 — so [the ENet
 phases] ship something that works on LAN or a VPS and nowhere else." Steam/SDR