[goose acp 復活 残作業] PR #384 で goose ACP のコード資産を復元し claim を dispatcher の LocalSql に re-home したが、server-α 下で「実際に動く」にはまだ server から content を読む経路が残る。同じ re-home パターン(server run_sql → 自前 LocalSql)で潰す必要がある。

## 残る α 破損(server の content 読み → 空振り)

PR #384 が直したのは eligibility/claim 経路だけ。以下は未対応で、放置すると該当レーンが無言で空振りする:

- **dispatch 側 / mention → goose:pr front door** ── `trigger_sweep` / `trigger_candidates_sql`(`acp_dispatch.rs`)が `post_mentions` + `current_tags` を server run_sql で引く。α で恒久空 → `@rail44.dev/goose` を mention しても何も enqueue されない。claim と同型で LocalSql 経由へ re-home(grounded: aside `n_01KT6MSV5PBP8ZZQEAW7DBXRA6`)。
- **serve 側 / ACP agent の corpus browse** ── `acp serve`(`acp_agent.rs`)が公開する backlog/search/open ツール(`acp_commands.rs` の `backlog_sql` / `search_sql` / `open_sql`)が `posts_current` + `current_tags` を server から引く。α で空 → ACP agent 経由の一覧 / 検索 / open が機能しない。同じく LocalSql 経由へ re-home。

(floor 読み = `group_encryption_enabled` / `group_recipients`(`groups_current` / `group_members`)は server が床として保持するので無傷 ── 触らない。)

## 実機 end-to-end 検証(未実施)

PR #384 の re-home(claim + dry-run)も上記 2 経路も、まだ live dispatcher+server で一度も走っていない(unit のみ green)。goose job を 1 件 enqueue → `acp dispatch goose --once` → LocalSql 経由で claim → 実行 → finalize、を実機で通す smoke が要る。

## robustness(後回し可)

- crash / finalize 失敗で残る stale-wip の自動回収。単一 dispatcher 前提では restart 時 self-reclaim / 手動 re-open で当面足りるので優先度低。

起点: PR #384(goose ACP 復元 + claim re-home)。#382(retire 決定 `n_01KT6EB18DAARD50KV0097KBM7`)の server-gate 撤去は維持、goose 資産だけ復元した補正。