AskUserQuestion: clarify path discards the selected option and the typed text (still present in 2.1.259)

Summary

When a user answers an AskUserQuestion and the interaction goes down the "clarify" path, both the selected option and any typed text are discarded. The model receives a tool rejection instead of an answer:

The user doesn't want to proceed with this tool use. The tool use was rejected...
To tell you how to proceed, the user said:
    The user wants to clarify these questions.
    ...
Questions asked:
- "<question text>"
  (No answer provided)

The user believes they have answered — they picked an option and typed a note — and the model is told nobody answered. The model then re-asks, the user gets annoyed, and the round trip is wasted. In our case the user replied: "Your output said I declined to answer, but I DID answer. Did you not get it?"

This was previously reported as #66224 (in French) and closed as not_planned on 2026-07-14 at version 2.1.168. It still reproduces on 2.1.259, and this report adds a detail that one does not have: it is not only the free-text that is lost — the selected option is lost as well.

Environment

• Version: 2.1.259
• Platform: darwin (arm64)
• Entrypoint: cli

Steps to reproduce

1. Call AskUserQuestion with a single question, multiSelect: false, and three options.
2. As the user, select one of the options and enter free text in the same interaction.
3. Observe the tool result delivered to the model.

Expected: the model receives the selected option, plus the typed text as an annotation.

Actual: the model receives is_error-style rejection text, the "user wants to clarify" boilerplate, and (No answer provided) for the question. Neither the option nor the text is present.

Why it matters

The failure is silent and misattributes intent. The model has no way to distinguish "the user declined to answer" from "the user answered and the answer was dropped", so its only correct move is to re-ask — which reads to the user as the model ignoring them. Any tool result that can silently replace an answer with "no answer" is worse than an error, because the model confidently acts on the wrong premise.

Related: #33511 ("Chat about this" sending is_error: true and discarding answers) describes the same class of problem on a different button, also closed not_planned.