[FEATURE]: a /btw answer is unrecoverable once its dialog closes #50879

Feature hasn't been suggested before.

• I have verified this feature I'm about to request hasn't been suggested before.

Searched issues and PRs in this repo for btw, side question, session.aside, btw history, btw reopen, btw persist, btw save, btw lost, btw dialog closed, aside history, dialog history. Existing /btw items are about adding the command (#16992, #41910, #46599, #44965, #49646, #49750) or crashes (#49777, #49878, #50415). #50391 adds a fork action inside the dialog and #38558 tracks the session.generate contract; neither covers recovering an answer after the dialog is gone.

Describe the enhancement you want to request

A /btw answer exists in exactly one place: the open dialog. session.generate is transient by contract, with no admission, events, usage or history write (#38558), and the docs state the answer "is not added to the conversation". So closing the dialog destroys the only copy, and the only escape hatch is pressing c before that happens.

This makes /btw unlike every other dialog in the TUI. Sessions, models, MCP, plugins and diffs all render state that can be reopened on demand. /btw is the only dialog whose content cannot be reproduced at all: a rerun costs another model call and returns a different answer.

At the same time it is the dialog that is easiest to discard by accident. Three separate one-step gestures destroy it, none of them undoable:

1. a single click anywhere on the dimmed backdrop, since the dialog wrapper attaches onMouseUp -> onClose to the full-screen overlay while the inner panel stops propagation, so any click outside the panel closes it
2. escape
3. ctrl+c, which is a common reflex immediately after reading text you want to keep

There is currently no way to soften any of the three from configuration. The escape and ctrl+c handlers are registered in the modal layer without a command id, so they do not appear in the keybind reference and cannot be remapped or set to none in cli.json. Backdrop dismissal is a mouse handler rather than a command, so keybinds cannot reach it at all. Disabling mouse globally is not a usable trade for this.

#50391 makes this sharper rather than better: adding f / Fork session increases what is lost when the dialog disappears, and both c and f only exist while it is open.

The request is that a /btw answer survive the dialog, or at least that a single accidental gesture not be the end of it. I have no preference between the possible directions: a command that reopens the last answer, a small in-memory ring of recent /btw question/answer pairs, opting this dialog out of backdrop dismissal, or giving the dialog close commands real ids so they can be rebound.

Environment

• opencode version: 2.0.14 (latest channel)
• OS: Linux 6.18.49-1-MANJARO, linux x64
• Terminal: ghostty (TERM=xterm-ghostty, COLORTERM=truecolor)
• Shell: zsh
• Active plugins: none configured via plugins; two local plugins present under ~/.config/opencode/plugins/ (worktree-bootstrap.ts, zj-radar.js), neither touching dialogs
• cli.json: mouse not set, so default capture is on