[aside] server は encryption-enabled group への平文投稿を拒否しない ── E2E の暗号化保証が完全に client 任せで、直結 client(CLI/API)は暗号化 group に平文を silently 流し込める。

PR #250(create_post の encrypted_payload 受理)+ dogfooding 完走で確定した scope 外の security 観察。

- 現状: `enable_group_encryption` は `groups_current.encryption_enabled=TRUE` を立てるだけ。`create_post`(`src/server.rs`)は body / encrypted_payload の「ちょうど片方」しか見ておらず、**target group が encryption_enabled かを一切照合しない**。なので暗号化 group に **plaintext body** を投げると、そのまま `encrypted=false` の平文として保存される(PR #250 も「片方だけ」検査で enforce は足していない)。
- 暗号化は **proxy(gateway)層の協力**だけが担保: `bridge --proxy` 経由なら body を暗号化して encrypted_payload に差し替えるが、**proxy を通さない直結 client**(`quacker-channel post create` / `sql` / 任意の MCP・HTTP 直叩き / 将来の SPA write)は平文をそのまま server に送れる。`enable_group_encryption` の doc 自身が「gateway/SPA がクライアント側で enforce する」と明記 = **flag は advisory**。
- 想定インパクト(footgun): user が「この group は暗号化されてる」と信じて `quacker-channel post create --audience <encrypted-group> --body <秘密>`(proxy 非経由)すると、**秘密が平文で prod に保存される**。しかも `encrypted=false` なので後から「なぜか 1 件だけ平文」状態になり気付きにくい。E2E の整合性が「全 client が行儀よく暗号化する」前提に乗っている。
- 今触らない理由: dogfooding の主目的(agent 経路の write/read 疎通)は達成済で、server enforcement は別軸の設計判断(client-enforced E2E を許容するか / server が拒否するか)。
- 方向案: `create_post`(と将来の write 経路)で、target group が encryption_enabled なら **plaintext body を reject**(encrypted_payload 必須)を server 側に足す。trade-off: proxy 非経由の plaintext 投稿が一律不能になる(暗号化 group では それが望ましいはず)。最低限「暗号化 group に平文が入った」を検知できる invariant にする。
- トリガー: 暗号化 group を本番運用に乗せる前、または直結 CLI を暗号化 group で使いたくなったとき。