[FEATURE]: Add ESC key navigation to return to provider list when connecting providers

[savonovv]

Problem

When using the command to add a provider, if a user misclicks or wants to select a different provider, they currently have to:

1. Press ESC (which closes the entire modal)
2. Type again
3. Start the selection process from scratch

This is especially frustrating on:

• Slow SSH connections with high ping
• Low-RAM devices (e.g., Raspberry Pi Gen 1)
• Any situation where the UI might be laggy

Proposed Solution

Allow users to press ESC while in the API key input or authorization code dialog to return to the provider list, instead of closing the entire modal.

Expected Behavior

1. User types
2. User selects a provider
3. User sees API key/auth dialog
4. User presses ESC
5. User returns to provider list (not modal closed)

Implementation

The fix involves:

• Adding prop to , , and components
• Handling ESC key in to call
• Using as the back action

[github-actions]

This issue doesn't fully meet our contributing guidelines.

What needs to be fixed:

• This appears to be a feature request, but the title does not start with [FEATURE]: as required by the Feature Request issue template. Please rename the title to start with [FEATURE]:.

Please edit this issue to address the above within 2 hours, or it will be automatically closed.

---

For keybind-related issues, please also check our pinned keybinds documentation: #4997

If you believe this was flagged incorrectly, please let a maintainer know.

[github-actions]

Thank you for updating the issue! It now meets our contributing guidelines. We appreciate you taking the time to fix it.

[savonovv]

Investigation notes from the attempted implementation:

Current dialog system uses dialog.replace as a single-slot modal stack.
ESC is handled globally in packages/opencode/src/cli/cmd/tui/ui/dialog.tsx and always pops the active dialog.
Provider connect flow opens provider list -> auth method -> API key/code dialogs via replace, not push/back navigation.
Adding local ESC handlers in prompt/provider dialogs can conflict with global ESC handling (ordering/race conditions), causing:
    modal closing to chat instead of going back
    temporary blink between modals
    focus not reliably returning to prompt input

Why this is tricky:

There is no first-class modal history/back semantics in the dialog API; back behavior is being emulated by replacing dialogs during close events.
Focus restoration currently depends on a remembered renderable that can become stale after replace/clear cycles.

Suggested direction:

Add explicit dialog navigation primitives (for example push/pop or replace with handled-close contract).
Define modal-level close behavior (close, back, noop) without timing hacks.
Add consistent focus restoration API (prefer explicit target focus on close).

I closed PR #14929 because point-fixes introduced regressions. Happy to reopen with a broader dialog-layer change if this approach is accepted.