[interpretation] LogModule engine 化 — content を「最初の domain」に載せ替える前の解釈合意

@rail44.dev/kneume 着手前の解釈合意です。note n_01KT47S86J + review n_01KT488N4 + ③ 関連コード(quacker-core の events/projection、server の lib.rs、gateway の local_sql.rs、migrate.rs)を読んだ上での理解。

## 私の解釈

quacker-core を generic な log engine に一般化し、既存 content(post / tag / group / curation / ref / anchor / embedding / feedback / agent_account / owner_did)を `content` core domain として `LogModule` 契約の裏に載せ替える。**挙動は不変・構造のみ移設**、behavior-identical test を gate に。agent_run domain / capture 配線 / server の content-blind 化は scope 外(別 brief / ③ 済)。

## 確認したい点

### 1. trait の深さと event の振り分け方
note の「content-specific な Event + apply を domain に収める」を素直に読むと、21-arm の `Event` enum と `Projection::apply` を `ContentDomain` の LogModule impl 内へ**移設**し、engine は共有 DuckDB connection を持って namespace ごとに dispatch する形(= full 一般化)。振り分け key は wire を変えずに済む **`aggregate_type` → namespace の静的マップ**(post/group/curation/… は全部 content)を想定 — envelope に `namespace` field を足す migration は behavior-identical を崩しやすいので避けたい。

これでいいか、それとも今回は **content の Event/apply は据え置きで `LogModule` trait + registry だけ導入し content を薄く wrap**(engine が generic な器であることだけ示し、apply 分割は agent_run が来る時)という浅い切り方か。前者は note 寄り・後者は risk 最小。

### 2. namespace 並列化のスコープ(③ で対象機構が消えている)
scope ②は「store / chunked replay / `_projection_meta` catch-up を namespace ごとに独立して回す」だが、コードを見ると **chunked replay は既に存在せず**(#318 で server content read-model ごと撤去)、**`open_at` / `_projection_meta` は本番 caller ゼロ = test-only**。今 live な fold 経路は 2 本だけ:
- server authz boot — genesis 一括 in-memory(`is_authz_event` で group 系のみ)
- gateway `LocalSql` — `seen`-set incremental catch-up、persistent meta なし

どちらも quacker-core の同じ `apply` を通る。content は persistent / chunked 機構を**一切使っていない**。

私の lean = **(a) live な apply-dispatch だけ namespace 化し、persistent meta / per-namespace migration / chunked replay の namespace-key 化は「agent_run(TTL/Rollup で永続が要る)が来る時の seam」として trait に口だけ残す**。今 persistent path を復活させて namespace 化すると live consumer ゼロの dead/test code を一般化することになり behavior-identical も測りにくい。(b) いや今 persistent も作り込む、なら方針変える。どっち?

### 3. behavior-identical test の形(両経路)
両 consumer は同じ core `apply` を通るので、**core-level の golden replay test**(代表的 event log を fold → posts_current / current_tags / curations_current / group_members / post_refs / post_mentions / agent_accounts 等 全 content table の row が移設前後で一致)が shared logic を担保、+ 各経路(server authz filter / gateway LocalSql fold)は「同じ row が出る」薄い wiring test、で「両経路カバー」を満たすと解釈。これで十分か、live な server+gateway 統合まで要るか。

ズレてたら直してください。reply 待ちます(5分 timeout、無ければ worktree 維持で待機)。