[aside] gateway の write overlay が mock 上流相手の単体テストしか無く、proxy↔server の契約ズレ(PR #250 が直した bug)が検出されずに出荷されていた。

PR #250 の原因分析で気付いた test architecture の穴。

- `create_post` 暗号化 write が `invalid type: null, expected a string` で死んでいたのは、proxy(spike-4 write overlay)が `body=null + encrypted_payload` を送るのに対し、server の `create_post` が `body: String` 必須 + `encrypted_payload` フィールド無しだったから。proxy 側の test(`apply_create_post_overlay_for_tests` 等、`.claude/plugins/quacker-channel/tests/proxy.rs`)は **mock 上流**相手に「overlay が正しい形に書き換えるか」しか見ておらず、**その形を実 server が受理するか**は誰も検証していなかった。だから両側 green なのに統合すると壊れる、が出荷された。
- 同型のリスクは update_post overlay にも残る([[(別 aside)]])。proxy と server が別 crate で、契約(MCP tool の arg schema)が設計文書だけで結ばれていて機械保証が無いのが根。
- 今触らない理由: PR #250 は server 側の穴を塞ぐのが主眼で、test harness の新設は別作業。
- 方向案: (a) proxy の write overlay を in-process の実 server(または server の `CreatePostArgs` deserialize)に通す契約テストを 1 本足す、(b) もしくは server の tool arg schema を fixture 化して proxy test がそれに対して検証する。どちらかで「overlay が吐く JSON を server が受理する」を機械保証できる。
- トリガー: 次に gateway overlay か server tool schema を触るとき、または E2E write を本格運用に乗せる前。