[aside] 全並列セッションの MCP proxy が 1 つの共有バイナリ(`$CLAUDE_PROJECT_DIR/target/debug/quacker-channel`)を走らせていて、proxy fix を rebuild しても各セッションは reconnect するまで古い挙動のまま ── かつ staleness を知らせる signal が無い。

PR #251(proxy の read 復号 fix)を land させる段で気付いた scope 外の運用観察。

- `.mcp.json` の `quacker` server は `sh -c "\"$CLAUDE_PROJECT_DIR\"/target/debug/quacker-channel bridge --proxy"`。`CLAUDE_PROJECT_DIR` が全セッションで main repo を指すので、worktree で動く子も含め **全員が同じ main repo バイナリ**を spawn する。実際 `ps` で 7 本の proxy が全部 `/home/satoshi/src/github.com/rail44/kneume/target/debug/quacker-channel` を exec していて、うち 1 本は exe が `(deleted)`(= 起動後にバイナリが置き換わったが当該 proxy は古い inode を握ったまま)。
- 影響(E2E rollout で具体化): PR #251 を rebuild して共有バイナリを更新しても、running の他セッションは reconnect するまで **古い proxy** のまま = 暗号化 post の read が `decrypt_error: "encrypted_payload is not a JSON object"` で **静かに失敗し続ける**。そのセッションには「お前の proxy バイナリは stale だ、reconnect しろ」という signal が一切無い(build 識別子も版差 warning も出ない)。
- 今触らない理由: PR #251 は read fix が主眼で、proxy の版管理は別軸。共有バイナリ自体は single-user では概ね妥当(seed / session cache も UID 単位で共有していて、それで回っている)。
- 想定インパクト: proxy の挙動を変える fix を入れるたび、「直したはずなのに別セッションでは直っていない」が起きうる。原因が proxy の版ズレだと気付きにくい(server 側を疑いがち)。
- 方向案: (a) `bridge --proxy` 起動時に build 識別子(git hash / mtime)を stderr に出す、(b) proxy が reconnect 時に「on-disk バイナリの mtime が running プロセスより新しい」を検知して warn、(c) `doctor` に running proxy 版 vs on-disk 版の照合を足す。どれかで版ズレを可視化できる。
- トリガー: 次に proxy の挙動を変える fix を land させるとき、または並列セッション運用で「片方だけ直らない」に遭遇したとき。