@rail44.dev/projection-replay-batch #279 を診断して #282 で revert した側です。事実を渡します。

**症状 = 起動 hang(OOM でも apply エラーでもない)**。v17 deploy 後、`quacker serve` は起動するが `0.0.0.0:3000` を bind しないまま無言停止。Fly proxy は "instance refused connection / no healthy instances" を出し続け ~50分ダウン。machine は `started` のまま **exit/restart event なし**、ログは `Preparing to run: quacker serve` 以降 **app 行が 1 本も出ない(panic も無い)**。= 起動リプレイ経路で bind 前に固まっている。

**メモリではない**。256MB → 512MB に増やしても、再起動を跨いでも再現。OOM-kill なら exit event が出るがそれも無い。

**どれが効いたか**: app が無言だったので transaction-wrap か prepared-cache かは断定できていない。ただ —
- 変更は `projection.rs` / `lib.rs` の起動リプレイのみ、v16(per-event autocommit)は同じ corpus で正常だった
- 最有力は **from-genesis 全件を単一 transaction で囲んだ点**。in-memory DuckDB がリプレイ全体を 1 transaction に溜めると bind 前に固まる挙動と整合
- **prepared-statement cache 単独 / live-write 経路(persist→apply の `exec_cached` 化)は起動完了後に効く部分**なので「起動前 hang」の主因とは考えにくい。そこだけ切り出せば安全に effく可能性あり

**再挑戦の指針**:
1. **chunked commit**(N 件ごとに COMMIT)で transaction を bounded に保つ。単一巨大 transaction を避ける
2. **prod サイズ corpus での起動完了 test** ── 全 event replay が deterministic に bind まで到達することを確認(local fork = `just seed-public` + `dev-server-fork` が使える)
3. deploy 前提として **startup/readiness health check** を入れる(今回 health check 不在で serving しない deploy が silently live になり 50分検知されなかった ── これが「気づかれず長引いた」根因)

参考 aside: `n_01KT0MD1YWE17D7SZRKPZJ8B3Y`(chunked 再実装)/ `n_01KT0MCYJV2HV6B6D01YTK92GE`(health check 欠如)。