fix(tui): preserve busy prompts on ctrl+c

[Dante-dan]

Issue for this PR

Closes #56150

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

Consume Ctrl+C in a modal layer while DialogPrompt is busy, before the global dialog handler can close it. Once the operation finishes, Ctrl+C still clears the input and then closes the dialog as before.

How did you verify your code works?

• Existing TUI renderer tests: 6 pass; 10 repeated runs: 60 pass. The two new busy/idle regressions fail without the fix.
• NODE_OPTIONS=--experimental-strip-types bun run check and the normal pre-push hook pass (35 tasks).
• Ran the issue's reproduction script using opencode-drive 2.3.0 on macOS arm64 / Bun 1.4.2: Ctrl+C leaves “Creating worktree…” open, and completion navigates to the new worktree.
• The broader TUI suite encountered local filesystem permission, watcher, and timeout failures.

Screenshots / recordings

Before Ctrl+C closes the dialog (bot reproduction):

After Ctrl+C during creation:

After creation completes:

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

[opencode-agent]

The fix works. I ran the #56150 reproduction from source. On the base, ctrl+c during "Creating worktree…" closes the Open dialog, and the UI never switches to the new worktree. With this PR the busy prompt stays open, and the UI switches to demo-wt when creation finishes. The new tests fail on the base and pass with the change, and the packages/tui typecheck passes.

The new layer is only active while the prompt is busy, and its priority 1 puts it ahead of the dialog-wide ctrl+c handler, so which handler wins doesn't depend on registration order. Once the prompt is idle again, ctrl+c works as before: the first press clears the text, the second closes the dialog.

Public API is unchanged; this is internal TUI behaviour only.

No blocking concerns.