fix(kernel,tools,workflow): session-robustness QA sweep

Uncommitted work from the session-robustness-and-dox branch sweep
(docs/qa/QA-session-robustness-and-dox.md), verified alongside the
compression/context fixes:

- SandboxedToolExecutor: validate tool args centrally before dispatch. A
  malformed/missing-arg call becomes a recoverable ERROR: (surfaced with the
  tool's arg schema so the model can correct + retry) instead of stranding
  the stage with no artifact. + validation test.
- PlanLinter: seed artifacts (analysis) produced by the planning phase count
  as available producers, so a plan stage that `needs` them isn't flagged as
  an unproduced-need; H1 unproduced-needs + trap-state checks. + tests.
- DefaultSessionOrchestrator: live-QA robustness fixes (event-tail /
  per-stage budget + retry handling).
- workflow prompts/configs: DOX AGENTS.md alignment + freestyle/task/role
  prompt tweaks.
- SessionOrchestratorIntegrationTest: coverage for the above.
- FreestylePlanningWorkflowTest: allow list_dir in analyst tools (follows the
  list_dir wiring in 968cbfa).
- QA plan doc for the branch sweep.

examples/workflows/prompts/analyst_freestyle.md

@@ -19,11 +19,13 @@ Then frame the work as a task (per the task policy):
 
 Either way later stages thread the named task through the plan; the rest wait to be claimed.
 
-Emit the `analysis` artifact (JSON, schema provided):
+Produce the `analysis` artifact by calling the **`emit_artifact`** tool with these fields:
 - `summary`: the goal in your own words.
 - `requirements`: concrete, checkable requirements, one per line.
 - `affected_areas`: files/modules likely involved, one per line.
 
+Call `emit_artifact` once you have read enough — do not write the JSON as a plain message.
+
 If — and only if — something genuinely blocks a plan (an ambiguous goal, a missing decision, a
 fork only the user can resolve), add a `questions` array. Each entry is an object:
 - `prompt` (required): the question, in full.
@@ -32,6 +34,11 @@ fork only the user can resolve), add a `questions` array. Each entry is an objec
 - `multiSelect` (optional, default false): true if more than one option may apply.
 - `header` (optional): a 1–2 word label for the question (e.g. "Scope", "Stack").
 
+Greenfield or new-surface work (a new UI, app, or module) almost always hides such a fork even
+when the high-level goal is clear: the build tool, styling approach, state/routing libraries, or
+component library are choices only the user can pin, and a placeholder instruction does not
+resolve them. Ask about stack/tooling in that case rather than guessing.
+
 Example:
 ```json
 {

examples/workflows/prompts/task_planner.md

@@ -9,7 +9,7 @@ already covers the goal, load it with `task_context` and name it in your summary
 
 ## Step 2 — Sweep the codebase (read-only)
 
-Use `file_read` (also lists a directory when given a directory path), `ShellTool` (grep, find, ls)
+Use `file_read` (also lists a directory when given a directory path), `shell` (grep, find, ls)
 to locate the files, modules, and patterns the request touches. Read broadly enough to understand:
 - what already exists
 - what the request changes or adds