[aside] #333 の envelope strip は復号成功行だけ ── 未 pair / 鍵違いの session が暗号化 group を bulk read すると全行が decrypt_error + full envelope を抱え、#333 が潰したはずの token cap がエラー経路で再発

PR #346(#333 = run_sql の encrypted_payload 肥大解消)実装中に確認した、修正の境界。

- 事実: `decrypt_row_if_encrypted`(proxy.rs)は **復号成功時のみ** `row.remove("encrypted_payload")`。no master seed / audience 欠落 / 鍵導出失敗 / 復号失敗 の 4 経路は debug 可能性のため envelope を残す(#333 推奨どおり、意図的)。
- だが #333 の元シナリオは「36 posts × ~4KB envelope ≈ 60KB で per-tool-call token cap 超過」。session が **未 pair**(master_seed 無し)だとその 36 行は全て decrypt_error 経路 → envelope を verbatim 保持 → 60KB のまま cap 超過。= #333 は **paired/成功ケースだけ**直り、未 pair の bulk read では同じ壁に当たる。
- 1 行 debug なら envelope 保持は妥当。問題は「多数行が一斉に error る」ケース(未 pair・別 group・鍵ローテ後)で full envelope が行数分積み上がる点。

触らない判断: 今回は #333 の主シナリオ(成功 read の肥大)解消が scope。error 経路の bloat 抑制は別軸(成功 strip と独立に効く)。

想定インパクト / トリガー: 未 pair or 鍵不一致の session が暗号化 group を `SELECT * FROM posts_view` で広く引いた時に token cap 再発(= 元の #333 体験の半分が残る)。緩和案: decrypt_error 行では envelope を full でなく「先頭 N 文字 + 長さ」に truncate して載せる(debug 可能性を最小限残しつつ行数スケールを断つ)、or full envelope を返す行数に cap。関連 PR #346、#333。