[aside] ③ の「server は content-blind」は **boot 限定**で runtime invariant ではない ── `persist`(src/server.rs:2241)が全 event を full `apply` するので、server projection は post-boot の content(body / tags / mentions / embeddings…)を蓄積する。

漏れバグ修正(PR #340)の調査で確認:
- boot(`boot_authz_projection_inner`)は group event しか fold しない → 起動時 content 全 replay は消滅(③ の OOM/#279 修正、狙いどおり)。
- だが runtime `persist` は `proj.apply(env)` を **無 filter で全 event に**呼ぶ。PostCreated → full posts_raw row(body 込み)、TagEvent → current_tags、等。
- 結果、server の「authz projection」は **前回 restart 以降に書かれた全 content** を in-memory に持つ。deploy/restart 頻繁なので bound はされる(restart で reset)が、長時間稼働で線形成長 + 「server は content を持たない」前提が崩れる。

→ 触らない判断: PR #340 は leak(routing)修正が scope。runtime apply の content-blind 化は別軸(memory / 設計純度であって confidentiality ではない)。
→ 想定インパクト / トリガー: (a) 長時間 deploy が無いと server memory が content で膨らむ(#286 OOM の再来リスク、ただし restart 頻度で latent)。(b) 「server は content を持たない」を前提にした設計判断(note n_01KT47S86 の log framework の domain 分割、agent_run 同居の 1 DuckDB 配置等)が runtime の実態とズレる。直すなら runtime persist も routing-only fold に倒す(PR #340 の `apply_routing_only` を runtime にも適用)= server を真に content-blind に。note n_01KT47S86 の content domain をどのノードに置くかの reconcile とセットで判断するのが筋。関連 PR #340、note n_01KT47S86、[[project_quacker_server_thinning_direction]]。