fix(ask): keep the keyboard up while an option is pressed during Other typing

[andrebrait]

Problem

Follow-up to #252, found testing it on Android Chrome. While typing in a question's Other box, tapping an option still did not choose it on the first tap. The tap moved focus off the text box, so the keyboard closed and the panel resized before the click, and the click missed the option. #252 only guarded the footer buttons.

Changes

• The focus guard moves from the footer to the whole dialog panel. On touch, while a text field in the panel has focus, a press anywhere in the panel outside a text field does not move focus. The click still fires, so the option, Cancel or Submit act on the first tap.
• A tapped option label still focuses its radio once the click lands (label activation), so the keyboard closes after the choice is made, not before it.
• Touch only ((pointer: fine) absent, the file's existing touchPointer()): a mouse keeps text selection and radio arrow-key navigation.
• Tapping back into kept Other text no longer fires a focus event (focus never left), so the textarea's click now re-chooses Other as well as its focus.
• Tests cover touch vs mouse, a focused field outside the panel, a focused radio inside it, and re-choosing Other by click. Each guard condition was mutation-checked: dropping any one fails a test.
• When an ask opens, the hidden composer gives up focus, so the keyboard it raised closes instead of staying up until the first tap in the panel (which then resized the panel and missed). Found testing on Android Chrome.
• On touch, only a focused text field counts as an open keyboard for the panel height. Focusing an option (Android focuses the radio on tap) used to switch the panel to the visible-area height under the finger, so the tap missed.
• Answering releases the panel's focus as the answer is sent, so the keyboard closes on Submit instead of after omp acknowledges it (plus the 250ms hand-off). When the keyboard is collapsed (back button) while a panel text field has focus, the field is blurred, so the next tap does not raise the keyboard again for a moment.
• CHANGELOG: the Unreleased entry from fix(ask): keep the keyboard up on a footer tap so Submit lands on the first tap #252 now covers option taps.

Verification

• npm test: 1401 pass, 0 fail. tsc --noEmit and eslint clean.
• Not checked on a physical phone yet: headless browsers do not raise a soft keyboard.