fix(tui): clear answer editing state when selecting other options

[aniruddhaadak80]

Issue for this PR

Closes #44192

Type of change

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

What does this PR do?

Mouse handlers call selectOption()/selectTab() directly and bypass the enabled: !store.editing gate on the keybindings. So after selecting "Type your own answer" (editing mode), clicking a preset option (or another question tab) picks it but leaves store.editing stuck on true. At the confirm tab both binding sets then refuse Return - the editing set requires !confirm() and the normal set requires !store.editing - so the answers can never be submitted.

This clears editing when a preset option is picked or the tab changes. Selecting the custom row still enters edit mode as before; keyboard-only flows are unchanged since those keys are already gated off while editing.

How did you verify your code works?

• Reproduced the flow locally in the TUI: select "Type your own answer", click a preset option, advance to confirm, Enter does nothing before this change and submits after.
• Keyboard-only flow (escape out of editor, arrows, enter) behaves as before.
• bun run typecheck clean in packages/tui; existing tui test suite shows no new failures.

Screenshots / recordings

Not a visual UI change.

Checklist

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

[Enough1122]

AI code review — automated review for reference, author can ignore or act on any point.

Correct root-cause analysis: mouse paths call selectOption()/selectTab() directly and bypass the enabled: !store.editing keybinding gate, so editing could stay true and permanently swallow Return on the confirm tab.

Details:

1. In selectTab (packages/tui/src/routes/session/question.tsx, hunk @@ -100,6, added line 103), consider early-returning when index === store.tab. As written, any click that re-triggers selectTab for the current tab clears editing even when the user is actively typing a custom answer, discarding editor focus/state unintentionally.
2. In selectOption (hunk @@ -118,6, added line 124), placement looks right — the custom-answer row must still end up with editing: true afterward, which relies on its branch running after this line. A brief comment pointing at that invariant (or an assertion in tests) would prevent future reordering regressions.
3. No automated coverage was added for the store transition (editing cleared on tab/option change, kept for the custom row). Even a small unit test around these handlers would lock in the fix described in issue TUI: If "Type your own answer" in question/ask prompt was selected and then switched to a different option, the answers cannot be submitted #44192.