feat(workflows): reviewer narrow-question + static-first framing (role-reliability §5)

The reviewer prompt told the model to judge "the analysis requirements," but
the reviewer stage only needed [patch, impl_plan] — it never actually received
the analysis artifact, so the acceptance criteria it was meant to check against
were never in its context. A reliability gate checking against criteria it
can't see is theater.

- reviewer now needs `analysis`, so the diff is judged against concrete,
  pre-stated acceptance criteria (§5 narrow question) rather than whole files
  against taste; the §3 minItems enforcement guarantees those criteria are
  non-empty.
- reviewer.md operationalizes §5's two principles: evaluate the diff against
  each requirement (findings must map to a requirement/plan-step/defect), and
  don't re-report what deterministic tools already catch (compiler/detekt/tests
  — trust verification, point at failures, don't re-derive them).

This is the workflow-level realization of §5. The full static-first
infrastructure (running static tools as a pipeline step and mechanically
excluding their findings from reviewer context) needs a static-findings event
representation and is deferred. §6 critic calibration needs runtime history
before it can say anything (spec ordering #5).

examples/workflows/role_pipeline.toml

@@ -69,11 +69,13 @@ allowed_tools = ["file_read", "file_write", "file_edit", "ShellTool"]
 token_budget = 32768
 max_retries = 3
 
-# 5. Review the patch against the plan; emit a structured verdict.
+# 5. Review the patch against the plan AND the analyst's acceptance criteria. The reviewer
+#    needs `analysis` so it judges the diff against concrete, pre-stated criteria (§5 narrow
+#    question) rather than whole files against taste.
 [[stages]]
 id = "reviewer"
 prompt = "prompts/reviewer.md"
-needs = ["patch", "impl_plan"]
+needs = ["patch", "impl_plan", "analysis"]
 produces = [{ name = "review_report", kind = "review_report" }]
 token_budget = 32768
 max_retries = 2