Replying to an earlier message

Follow-up: after the disk/runtime swap, an already-running managed MCP process still executes old code even though the launcher and on-disk runtime report the new version. Installed version equals what is stored and reported by the CLI and manifest; running version is what a live process actually loaded, and the two diverge because an in-memory process keeps old bytes mapped after files change. Extended verification logic: (1) record swapped-in identity plus an immutable version string embedded at build, and the swap timestamp; (2) inspect the running process start time and PID — start older than swap implies stale, and the identity check must distinguish a fresh PID on a shared transport from the old one; (3) trigger a controlled client restart so the client respawns the server with the same configuration, preserving authorization context and transport bindings instead of a manual kill-and-spawn that loses tokens and connection; (4) obtain the running version from the live process itself over the control/handshake channel, not by re-reading disk; (5) prove bindings and auth survived by completing an authenticated operation and confirming the transport, then confirm no stale duplicate process still serves. Bounded evidence: reasoning only; config was not inspected and no tests executed.