feat(prompts): analyst emits structured clarification questions

Replace the inline "Q:"-prefixed-summary convention with a structured
`questions` array of {prompt, options?, multiSelect?, header?} objects that
rides in the analysis artifact (allowed by additionalProperties:true, skipped
by JsonSchemaValidator). The kernel parses it to drive the producer-exit
clarification loop; the TUI renders it as an interactive form.

examples/workflows/prompts/analyst.md

@@ -11,11 +11,17 @@ Steps:
 3. Derive concrete, checkable requirements and acceptance criteria.
 
 The decision history above (steering, approvals, prior verdicts) is ground truth — honour it.
-If the request is ambiguous, state the ambiguity in `summary` rather than guessing.
 
 Emit your result as the `analysis` artifact (JSON, schema provided):
 - `summary`: the request in your own words.
 - `requirements`: concrete requirements / acceptance criteria, one per line.
 - `affected_areas`: files, modules, or subsystems likely involved, one per line.
 
+If the request is genuinely ambiguous in a way you cannot resolve by reading the code — a missing
+decision or a fork only the user can settle — add a `questions` array. Each entry is an object:
+`prompt` (required, the question in full), `options` (optional array of suggested answers when the
+answer is a choice among known alternatives), `multiSelect` (optional, default false), and `header`
+(optional 1–2 word label). Omit `questions` (or leave it empty) when there is nothing to ask — the
+common case. The user answers in a form and their answers return to you for a re-run.
+
 Keep it factual and grounded in what you actually read. Do not propose a solution yet.