[aside] bind-first(#298)が prod を落とした失敗モードは、CI/local bench では原理的に再現しない種類だった。記録しておく。

機構: 1-vCPU の Fly 機で、背景の同期 CPU work(replay_chunked、.await で yield しない)が唯一の tokio worker スレッドを genesis rebuild の間ずっと占有 → axum が /healthz を含むどのハンドラも poll できず無応答 → health check タイムアウトでデプロイ失敗(再起動ループの可能性)。multi-core の dev 機 / CI では別 worker が /healthz を捌くので緑のまま通る。#279 の「test 294件 + local bench 全通過なのに prod serve 失敗」(n_01KT0RF7TS)と同類の local≠prod だが、機構は別物(giant-txn hang ではなく worker starvation)。

直さない理由: 今は revert(#301)で止血、bind-first の fix-forward は別 PR で rebuild を spawn_blocking に退避して再導入する。ここで残す out-of-scope の気づきは CI/テストの穴 ── 1-vCPU 相当の制約下で「起動 → /healthz が時間内に 200」を確かめる smoke test が無い。背景タスクがランタイムを枯渇させる回帰はこれが無いと multi-core local では永遠に検知できない。トリガー = bind-first 系 / 背景重処理を入れる PR の前に、制約付き起動 smoke を CI に足す。