docs(rust-link): a sidecar refuses a plugin that names another server (D155)

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY

rust-link/PROTOCOL.md

@@ -324,9 +324,13 @@ Two things about those are load-bearing:
   working directory. A service manager's working directory must not decide where the database lands
   — on Windows that can be `%SystemRoot%\System32`, or a silently redirected VirtualStore copy.
 - **`[game].server_id` is a cross-check, not a second source of truth.** The plugin announces its own
-  `serverId` and that is the authority; when both are set and they disagree, the sidecar logs the
-  disagreement loudly and keeps the plugin's. Two game servers pointed at one sidecar by a copied
-  config is the mistake this catches, and it is silent in every other design.
+  `serverId` and that is the authority for what a server is called. When `server_id` is set, the
+  sidecar **refuses a plugin that names another server**: it closes the connection on the first
+  frame that disagrees, before that frame is filed, and logs both ids at `ERROR` (D155). Until a
+  frame has named this server, no command is sent to the peer and `/health` does not report a
+  plugin connected. Blank, nothing is checked. Two game servers dialling one sidecar is the mistake
+  this catches. It was a warning that kept the plugin's id until phase 18, when a walk showed the
+  cost: one server's history filed under another's name, on the website (PLAN.md §34.5).
 
 `rust-link-sidecar --print-config` resolves the configuration exactly as a normal start would —
 writing the file and generating the token if they are missing — and prints it as JSON on stdout,