[li-xiu-qi]

Fixes #253

Problem

RPC mode already speaks the extension dialog protocol: ctx.ui.select() and ctx.ui.input() are translated into extension_ui_request / extension_ui_response messages, and ctx.hasUI is true because those methods are functional. Despite that, clarify_user refused to run in RPC: executeQuestionnaire accepted only mode === "tui", so every RPC call failed with Error: clarify_user requires an interactive UI.

A second correction was needed on the same gate. The RPC context does expose custom(), but it returns undefined and cannot render a native TUI dialog. Gating only on typeof ctx.ui.custom === "function" would therefore send RPC down the native-dialog path and lose the question entirely.

Changes

• Accept tui and rpc in executeQuestionnaire; print and json keep returning the "requires an interactive UI" error.
• Use the native dialog only when ctx.mode === "tui" and ctx.ui.custom is callable. RPC reuses the existing executeFallback, so no new protocol messages are introduced.
• Pass ctx.signal to the fallback select / input calls, so both a client-side cancellation and an Agent abort end a pending question. Late responses are dropped by the existing RPC pending map.
• Reject empty or whitespace-only freeform answers, responses that do not match an offered option label, duplicate question ids, and duplicate option labels with explicit error results.
• Render error results with the error text instead of the generic cancellation label.
• Update the RPC protocol documentation and add the #253 regression suite.

Behavior and compatibility

• No protocol change: RPC clients keep receiving the same select and input requests with the same shape.
• Question groups, question ids, structured option values, and freeform answers are preserved; a freeform answer still arrives as a follow-up input request.
• Argument validation and cancellation semantics are unchanged, including that a cancelled questionnaire issues no further questions.
• Empty freeform answers and unoffered option responses now return an explicit error result. That result still sets details.cancelled: true; clients should display the error text rather than treating it as a user cancellation.
• Answering a questionnaire does not trigger plan approval; plan behavior is untouched.
• The native TUI dialog is unchanged and is still the path taken in tui mode.

Validation

Final HEAD is 934d590dedc452f40b230ab1fca6d31dc43e3687.

• cd packages/coding-agent && pnpm exec vitest --run test/suite/regressions/253-rpc-clarify-user.test.ts: 10 tests passed.
• cd packages/coding-agent && pnpm exec vitest --run test/suite/regressions/253-rpc-clarify-user.test.ts test/step-capabilities-extension.test.ts test/rpc.test.ts test/rpc-jsonl.test.ts test/rpc-prompt-response-semantics.test.ts test/rpc-client-clear-queue.test.ts test/rpc-client-clone.test.ts test/rpc-client-process-exit.test.ts: 7 files passed and 1 skipped; 27 tests passed and 18 skipped.
• Root pnpm run check passes.
• The focused suite includes a renderResult assertion proving the empty-freeform error path renders the error text rather than "Clarification cancelled".
• The abort test settles the execution after abort without a fixed short timeout and then verifies that a late response adds no output.

Limitations

GitHub CI on Ubuntu with Node 22 passed for the final head: build-check-test and Check commit attribution are both successful.

The native TUI dialog still ignores an empty editor submission instead of returning the new explicit RPC error. That is pre-existing TUI behavior outside this PR's RPC scope; RPC clients need no additional integration because the protocol frames are unchanged.