fix: Codex セッションのモデルが一覧に出ない（問い合わせが早すぎて必ず空振りしていた）

[takecchi]

概要

/agent で Codex に切り替えて始めたセッションのモデル欄が一覧で空のままになる問題を直します。
#121 で「rollout の turn_context を読む」仕組みを入れましたが、実バイナリで計測すると
一度も答えを拾えていませんでした（問い合わせが早すぎて必ず空振りする）。

原因（実測 codex-cli 0.147.0）

実際に codex exec --json を走らせて計測した順序:

時刻（thread.started 基準）	起きること
+0.0s	stdout に thread.started
~+0.2s	rollout ファイルが作られる（session_meta が先）
~+3.0s	turn_context（モデル slug）が書かれる（入力 response_item と world_state のあと）
+7.2s	turn.completed

つまり turn_context は「ターン開始時」ではなく約 3 秒遅れて書かれます。
一方 codiva 側は thread.started を見た直後に問い合わせ、200ms × 6 回 = 最長 1.2 秒
（さらにファイル探索の上限 MAX_ROLLOUT_SEARCHES で実質 0.6 秒）で諦めていました。

空振りを記憶しない作りにはなっていましたが、引き直す契機が次の thread.started しか無いため、
1 ターンで終わるセッション（一度指示して結果を待つ = いちばん普通の使い方）では
モデル欄が永久に空のままでした。

修正

• ターンが終わったあとに引き直す（本命）。その時点なら turn_context は必ず書かれているので当たります。
  猶予は短く（1.5 秒）— ここだけは await するため、取れない環境でターンの合間を引き止めません。
• ターン中の問い合わせは猶予を 20 秒に伸ばし、指数バックオフで読み直す。誰も待たないので長くても害が無く、
  長いターンでは走行中にモデル欄が埋まります。
• ファイル探索の回数上限を外す（猶予そのものが上限）。rollout ファイル自体も thread.started の
  あとに作られるため、「数回探して無ければ諦める」だと出現を待てずに空振りしていました。
• 空振りの予算は 4 回に（1 ターンにつき最大 2 回消費するため）。

テスト

• ローカルで lint / typecheck / test / build を通しています（CI でも確認）。
• 回帰テストを追加:
  • codex-adapter.spec.ts「re-asks at the end of the turn when the in-turn lookup was too early」
    = 今回の本命（1 ターンで終わるセッションでもモデルが届く）
  • codex.spec.ts「keeps looking for the rollout file until the deadline」= 探索上限の撤去
  • codex.spec.ts「gives up within the patience window it was given」= 猶予は必ず守る
• 実バイナリでの前後比較（/tmp の使い捨てリポジトリで 1 ターン）:
  • 修正前: session_started → assistant_text → turn_completed … model_resolved が一切来ない
  • 修正後: 3.45s model_resolved gpt-5.6-sol が届く

[takecchi]

レビュー完了です。追加の修正指摘はありません。

主に次の点を確認しました。

• thread.started 直後の問い合わせが、rolloutファイル自体と turn_context の遅延生成を猶予内で待てること
• ターン中の長い問い合わせをストリーム側でawaitせず、通常の応答を止めないこと
• ターン終了後に短い猶予で再問い合わせし、1ターンだけのセッションでも model_resolved を出せること
• ターン中と終了後の問い合わせが並行しても、解決済みモデルの重複が状態を壊さないこと
• /model の明示指定が遅れて届いた既定モデルより優先され、既定へ戻したときは探索予算が復元されること
• 中断・abort時は終了後問い合わせを行わず、遅い回答を別providerの状態へ流さないこと
• rolloutの探索が日付上限なしで、ファイル出現前からdeadlineまで継続すること
• 指数バックオフが指定された猶予を越えて待たないこと

確認結果:

• PR用worktreeで関連4ファイル: 108 tests passed
• npm run typecheck: 成功
• GitHub CI check: 成功

実測した書き込みタイミングに合わせて、ターン中の非同期探索と終了後の確実な再取得を分けた修正は妥当です。取れない環境では空振り予算と短いtail猶予で負荷・待ち時間も制限されています。