feat(ask): opt-in multi-select for ask_user_choice

[xabilarra]

Before submitting

• I searched open and closed issues and did not find a request for this feature.
• I reviewed this request and removed credentials, tokens, private paths, hostnames, and other sensitive data.

Problem or opportunity

ask_user_choice is the compact native list for one exactly representable decision: a single question, 2-4 ordered options, and one opaque value returned. Multi-select currently exists only in ask_user_question (#1274), and that tool is a heavier dialog: one to four questions, per-question tabs, preview panes, notes, and a Type something. row that is always present.

A caller who needs several selections from one closed set therefore has to choose between two unsatisfying paths:

• The compact list, once per selection. N dialogs, N envelopes, and the caller re-validates a set it could have received in one result.
• The questionnaire. Correct, but it pulls in the full dialog chrome and an always-available free-text row for what is otherwise a closed, exactly-representable decision.

Considered separately: ask_user_choice is also the tool Gentle uses to relay provider-owned consent envelopes, where exactly one opaque token is the whole point. That is why this capability is worth bounding rather than simply adding: multi-select must not leak into that path.

Who benefits: any flow that takes a set of closed answers in a single step — selecting several lenses, several targets, or several flags — without paying for the questionnaire dialog.

Proposed outcome

An opt-in multi-select mode on ask_user_choice, default off, that preserves every existing guarantee:

• New optional parameter (name is yours to choose), default false. When absent, single-select behavior stays identical.
• When enabled: the same one question and the same 2-4 ordered options render as togglable rows in the existing NativeChoiceList, with the current pointer and keyboard model, and the result carries a set of the selected opaque value tokens plus their labels — not one token.
• Cancel stays distinguishable from "nothing toggled": an empty commit must never be reported as a selection.
• allowCustomResponse remains independent and still opt-in; the existing prohibition on enabling it for provider-owned consent prompts and maintenance authorizations does not change.
• The consent path stays single-token by construction. If that can be enforced at the tool boundary, a multi-select call for a provider-owned consent envelope should be rejected rather than silently accepted; if it cannot be enforced there, please say so in the docs so callers keep the rule.
• No confirmation popup and no separate confirm button. Selection, Ctrl+C/Escape cancel, and the existing availability reconciliation (reconcileToolAvailability) keep working as they do today.

Alternatives considered

• ask_user_question with multiSelect: true — already works and needs no change. Rejected as the answer to this request: it brings the whole questionnaire dialog (tabs, previews, notes, always-available custom row) for a single closed question, so the two tools still are not interchangeable at the compact end.
• Ask once per selection and merge the answers — N dialogs, N envelopes, and set-level validation moves to every caller.
• Add multi-select to the consent surface itself — explicitly a non-goal here: consent is one opaque token.
• A new dedicated multi-select tool — possible, but it would duplicate the list view, the pointer interaction controls (feat(ui): add composable native pointer interaction controls #648), and the closed-choice projection ask_user_choice already carries.

Additional context

• ask_user_choice arrived as the native closed-choice selector (fix(pi): add native closed-choice selector #452), and was extended by the Herdr closed-choice projection (fix(compat): project closed choices to Herdr #482) and by opt-in custom responses.
• Reference implementation to borrow from: lib/questionnaire/schema.ts (multiSelect) plus the togglable rows and selected[] propagation in lib/questionnaire/questionnaire-view.ts.
• Observed on: gentle-pi 3.3.0, Pi 0.86.1, Linux (WSL2).