Delay approval prompts while typing

[etraut-openai]

Why

Fixes #7744. Approval modals can currently appear while the user is typing ahead in the TUI composer, which lets plain letters like y or a get consumed as approval shortcuts instead of staying in the draft input.

What changed

• Track recent composer typing activity in bottom_pane/mod.rs.
• Delay new approval overlays for 1 second while the composer is active, keeping delayed requests queued until the user is idle.
• Preserve the existing active-overlay behavior so approvals that arrive while an approval modal is already open are still queued into that overlay.
• Prune delayed approvals when app-server resolution says the request has already been handled.

Verification

Added unit coverage for immediate approvals, delayed approvals, idle deadline reset, typed shortcut letters staying in the composer, shortcut handling after the delay, and resolved delayed-request pruning.

Focused codex-tui test groups pass locally. The full cargo test -p codex-tui run currently aborts in app::tests::attach_live_thread_for_selection_rejects_unmaterialized_fallback_threads; that same test also fails when run alone with the same stack overflow.

Manual reviewer check:

1. Start the TUI from the repo root:

   RUST_LOG=trace just codex \
     -c log_dir=<temp-log-dir> \
     --ask-for-approval untrusted \
     --sandbox workspace-write

2. Submit this prompt:

   create a file text.txt on my desktop
   

3. While the agent is preparing the approval request, immediately type text such as ya this should stay in the composer.

4. Confirm the typed-ahead y/a remains in the composer instead of approving the request.

5. Stop typing for about 1 second; the approval modal should then appear.

6. Once the modal is visible, press y and confirm the approval shortcut works normally.

[fcoury-oai]

Just curious: were you able to replicate this problem by hand? I tried by couldn't.

Codex found an edge case that is very simple to fix. I am proactively approving it.