Question panel: a digit typed into the answer field picks an option instead #1093

What happens

With an agent question panel open, the free-text answer input has focus (it inherits it from the composer). While that input is empty, typing 1–9 picks the matching option and the digit never reaches the answer field. An answer can only start with a number after some other character has been typed first.

Steps to reproduce

1. Have an agent ask a question with options (single- or multi-select).
2. Leave the caret in the answer field; don't click anything.
3. Type 1.
4. Option 1 is selected and the field stays empty.
5. Type , and then 1: the field now accepts the digit (1,).

Expected

Typing into the focused answer field inserts text. Answers such as 2.5s, 8080 or 1st option must be possible without a throwaway first character. Picking an option should not steal a keystroke from a focused text field.

Cause

crates/ui/src/composer.rs, Composer::on_wizard_key:

if let Ok(digit) = key.parse::<usize>()
    && (1..=9).contains(&digit)
    && !event.keystroke.modifiers.modified()
{
    if !input_focused || input_empty {
        self.wizard_select(digit - 1, cx);
        cx.stop_propagation();
    }
}

The answer input keeps the composer's focus, so input_focused is true and, on a fresh panel, input_empty is also true: every bare digit is consumed as an option pick. The stop_propagation was added deliberately so the digit is not both picked and inserted, which makes the ambiguity explicit.

Suggested fix

Let focus decide, with no modifier chord involved:

• While the answer field has the caret it owns every key, digits included. Drop the input_empty half of the guard: that is the whole bug.
• A press anywhere else in the panel moves focus to the panel, and there bare digits pick options and Enter advances. The field already blurs itself on presses outside its bounds (on_mouse_down_out), so the panel only has to take focus when it sees the press.
• Clicking the field brings the caret back, and so does a page change or the panel closing, because those pages are answered by typing.

Picks stay scoped to the panel: a digit only picks while the panel (or its answer field) has focus. With focus elsewhere the digit belongs to whatever the user is typing in, so nothing is stolen. The panel takes focus on open and on any press inside it, which covers the answering path.

Open question: should a visible panel claim bare digits even when focus is elsewhere (terminal, editor, sidebar search)? This proposal keeps them scoped on purpose, but it is worth deciding explicitly.

Modifier accelerators were considered and rejected: Alt/Option + digit prints ¡ on US and [ on German, so it would take those characters away from the answer field; ⌘1–⌘9 collides with the session jumps and, on macOS, with the native menu key equivalent.

Happy to send a PR with regression tests for each path.

Version: v0.2.129, macOS.