fix: 質問待ちの詳細ビューで会話ログを遡れるようにする（Tab で切替）

[takecchi]

背景

セッション詳細ビューは pendingPermission があるあいだキーを全部 PermissionDialog へ委譲していたため、↑↓ / PgUp / PgDn がすべて選択肢の移動に食われ、会話ログを 1 行も遡れなかった。結果、「何の話か分からないまま質問に答える」しかない状態だった。

一覧画面には同じ問題への答え（ListFocus = composer / dialog / list を Tab で回す）が既にあるので、詳細ビューにも同じ考え方（↑↓ が指す対象を一意にする）を持ち込む。

変更

• DetailFocus（dialog / log）を追加し、許可/質問待ちのあいだ Tab で往復する。
  • 既定は dialog — 回答は待たせている用事なので、そこへ辿り着くために Tab を踏ませない（一覧の zoneForRow と同じ方針）。
  • log ゾーンでは ↑↓ / PgUp / PgDn がログのスクロールに戻る。ダイアログは active={false} で表示のまま（質問文を読みながら遡れる）。
  • 回答へ戻る経路は Tab / Esc / ダイアログのクリック（onActivate）の 3 つ。
  • 回答の途中経過（何問目か・チェック済みの選択肢・書きかけの自由記述）は内部 state なのでアンマウントしない（一覧と同じ）。
  • pending が解けたらゾーンを dialog へ畳む（次の質問でキーの意味が勝手に変わらないように）。
• マウス: ホイールはゾーンに関係なく通す（押下と違い副作用が無く、背景を読む第一の手段）。押下系は log ゾーンだけ通すので、範囲選択と URL クリックも普段どおり使える（dialog ゾーンでは従来どおり飲む）。
• 文言: detail.helpLog / detail.dialogInactiveHelp を ja/en に追加し、detail.helpPending に Tab の案内を足した。PermissionDialog の「表示のみ」ヒントは view から渡す（inactiveHint）— 一覧の「↑↓: セッション切替」は詳細では嘘になるため、共有コンポーネントに view の知識を持たせない。
• ドキュメント: .claude/rules/ink-components.md（ゾーンの不変条件・マウスの例外）/ docs/ARCHITECTURE.md（SessionDetail の責務）/ README.md（利用者向けのキー表）を実装より先に更新。

テスト

tests/app.test.tsx に統合テストを追加（許可待ちでも Tab でログを遡れ、Tab で回答へ戻れる）:

• dialog ゾーンでは ↑ でログが動かない（ダイアログのもの）
• ホイールは dialog ゾーンでも効く
• Tab → log ゾーンでフッタ/ダイアログの案内が入れ替わり、質問文は表示されたまま
• log ゾーンの ↑ でログを遡れ、「過去ログを表示中」が出る
• Tab で戻ってそのまま y で許可できる（往復でダイアログが壊れない）
• lint（Biome）/ typecheck / test（tests/app.test.tsx 99 件）/ build の 4 点

体感確認（実 TTY + 認証が必要）はお願いします: 詳細ビューで質問が来ている状態で Tab → ↑↓ でログが遡れること、Tab / クリックで回答へ戻れることを確認してください。

🤖 Generated with Claude Code

[takecchi]

レビューしました。追加の指摘事項はありません。LGTM です。

DetailFocus によってダイアログとログのキー操作が明確に分離されており、ダイアログをアンマウントせず active だけを切り替えるため、回答途中の内部状態も保持されます。ホイール、クリック、Esc、Ctrl+C の各経路についても既存の PermissionDialog 側ハンドラーとの競合を確認しましたが、問題は見つかりませんでした。

確認結果:

• 追加された「許可待ちでも Tab でログを遡れ、Tab で回答へ戻れる」テスト成功
• npm run typecheck 成功
• npm run build 成功
• GitHub CI 成功

補足: ローカルで全テストを並列実行した際、今回の差分外にある既存の非同期テストがタイミング依存で失敗しました（hooks.spec.tsx 3件、app.test.tsx 5件）。hooks.spec.tsx は単独再実行で 7/7 成功し、対象の新規統合テストも成功しているため、本PRの不具合とは判断していません。