fix(chat): submit AskUserQuestion answers keyed by question text

[hanifnr]

Summary

• Braid was sending AskUserQuestion answers keyed by q.header (the short chip label), but the Claude Agent SDK expects them keyed by q.question (the full question text — see AskUserQuestionOutput in @anthropic-ai/claude-agent-sdk: "question text -> answer string").
• As a result, the SDK couldn't correlate the user's selections with the asked questions, and Claude effectively saw the answers as unreadable.
• Fix: iterate pendingQuestion.questions and emit each answer under q.question. Drops the now-unnecessary header→question lookup and makes the "other" override precedence explicit.

Root cause

• Schema (AskUserQuestionOutput.answers, sdk-tools.d.ts:2666): keys are question text → answer string.
• SDK CLI uses answers[V.question] when rendering / formatting the tool result back to the model.
• AskUserQuestionPrompt.tsx#handleSubmit previously keyed final by header, so the lookup failed silently downstream.

Test plan

• Run a session and trigger AskUserQuestion with a single question — verify Claude correctly reads the chosen option.
• Trigger AskUserQuestion with multiple questions — verify Claude correlates each answer with the right question.
• Select the "Other" option and submit free-text — verify Claude reads the typed value.
• Multi-select question: pick several options + Other (no text) — verify Claude reads the joined labels.
• yarn test passes (pre-existing unrelated failures in lsp/helpers and useSwipeNavigation remain).

[gemini-code-assist]

Code Review

This pull request updates the handleSubmit function in AskUserQuestionPrompt.tsx to use question text as keys for the final output, ensuring compatibility with the SDK. The implementation was also changed to have free-text 'other' values override selections. Feedback suggests merging these values instead of overriding them to prevent potential data loss in multi-select scenarios.

[hanifnr]

@gemini-code-assist Thanks for the review. Addressed the data-loss concern in a77019c — multi-select labels and "other" free-text are now merged into a single comma-separated answer instead of overriding, matching multi-select semantics. Single-select behavior is unchanged because the UI replaces selections with ['__other__'] when Other is picked, so the merge degenerates to just the "other" text.

[gemini-code-assist]

Thanks for the update, @hanifnr. The logic in handleSubmit now correctly aligns with the AskUserQuestionOutput schema by using q.question as the key and merging multi-select labels with