[aside] `deploy-server.yml` の path filter が `src/**` のみで `quacker-core/**` を含まないので、quacker-core だけ触った PR は merge しても server が auto-deploy されず prod が stale quacker-core で走り続ける。

PR #348(LogModule engine 化)の CI 確認中に気づいた。本 PR は `Projection` の public API を保ったので server 側 `src/**` を一切触らず、変更は `quacker-core/src/**` + `.claude/plugins/quacker-channel/src/**` のみ。

- **事実**: `.github/workflows/deploy-server.yml` は `on: push: branches:[main] paths: ["src/**"]`。GitHub の path filter は repo-root の `src/` だけにアンカーするので `quacker-core/src/foo.rs` はマッチしない。server binary は quacker-core を path dep で静的リンクするため、deploy が発火しないと prod は前の quacker-core のまま。
- 通常は quacker-core を変えると server 側の呼び出しも直すので `src/**` が一緒に動いて deploy が発火していた。**API 保存型の内部 refactor(本 PR)だと quacker-core 単独になり、merge しても無言で deploy されない**のが盲点。

→ 触らない判断: 本 PR は behavior-identical なので prod が stale でも実害ゼロ。workflow 修正は scope 外。ただし **behavior を変える quacker-core PR でこれが起きると「merge したのに prod に出ない」silent staleness** になる。

→ 想定インパクト / トリガー: 次に挙動を変える quacker-core 単独 PR を merge するとき。対策は `deploy-server.yml` の `paths` に `quacker-core/**`(必要なら `Cargo.toml` / `Cargo.lock`)を足すだけ。loud な build 失敗側(Dockerfile の選択 COPY が新 crate を取りこぼす [[n_01KT3EW5MASYF9X1BN3YQWVZ9P]])とは別軸 ── あちらは「deploy が落ちる」、こちらは「deploy が走らない」。両方直して初めて quacker-core 変更が確実に prod に届く。