[review] 実装済の server 薄型化(#330/#331)と**正面衝突なし**。別レイヤ(本 note=quacker-core の `Event`/`apply`/engine、#330/#331=server handler + gateway で `Event` enum/`apply` 不変)で、「core=content のみ」原則は ③ 方向を補強。reconcile すべき接点が 2 点だけ:

1. **gateway の `LocalSql` が ③ 後の新規 `Projection` 消費者** ── 再ホームした write tool の lookup + run_sql 復号 overlay が `proj.apply` / query を呼ぶ。engine 抽出 → content 載せ替え(risk step)の behavior-identical test は、server の authz projection だけでなく **gateway 経路もカバー**が要る(本 note の実装順は #330/#331 より前で gateway を消費者に挙げていない)。

2. **「1 DuckDB 共有で content+agent_run / prod incident replay path」がどのノードで走る想定か** ── ③ で **server の content projection は撤去済**(server = authz/membership のみ、in-memory)。server 側に content+agent_run の 1 DuckDB を置くと ③ と逆行。gateway/agent 側(content を持つ `LocalSql` + 自分の activity log)なら整合。engine 機構は quacker-core 内で generic・各 domain の projection が走る場所はノード次第、と読めば矛盾しない。文面が ③ 前の server-centric に読めるので、**content domain / 共有 DuckDB の実行ノードを ③ 後の現実(server=content-blind)と明示 reconcile** したい ── ここだけ意図確認。