feat(mode): ask_user_question joins the plan allowlist; the section steers to the exit tool

Live-session feedback (a real Zed elicitation round-trip): the model
presented its finished plan as a plain reply and asked the USER to
switch modes — the exact reversal the roadmap warns about — because the
shipped section's 'present it with the exit_plan_mode tool' read as a
suggestion. The section now says a finished plan is delivered by
calling exit_plan_mode, preferred over pasting it as a plain reply or
asking the user to switch modes — firmer, without imperatives.

ask_user_question enters the shipped plan allowlist (asking is
read-only-safe), and the section points a blocked decision at it. The
plan-acp-agent example composes the bash family (default mode only —
plan's allowlist keeps excluding it, so the two modes now demo a real
difference) plus tool-ask-user; both recorded scenarios re-recorded:
the pin now shows plan = [ask_user_question, exit_plan_mode, read,
todo_write] and post-exit default = the full eight-tool surface.

examples/plan-acp-agent/cordis.yml

@@ -45,6 +45,23 @@
 - id: mode
   name: '@deepseek-ai/dsh-mode'
 
+# Local bash executor + the model-facing bash tools: available in the default
+# mode, EXCLUDED by plan mode's allowlist — running the two modes against the
+# same task shows the difference (`rm`/`git` work only after the exit review).
+- id: bash
+  name: '@deepseek-ai/dsh-bash-local'
+  config:
+    timeoutMs: 60000
+
+- id: tool-bash
+  name: '@deepseek-ai/dsh-tool-bash'
+
+# The model-facing ask_user_question tool: ON plan mode's allowlist, so the
+# model can raise a blocking decision to the user while planning; the review
+# and the questions ride the same elicitation flow.
+- id: tool-ask-user
+  name: '@deepseek-ai/dsh-tool-ask-user'
+
 # Filesystem capability stack: local provider, read-before-write/edit policy
 # gate, then the model-facing read/write/edit tools — `read` is on plan mode's
 # allowlist; `write`/`edit` are what the plan-mode gate denies.