ah-4el Review-verdict-driven transition: changes-requested back to Ready for coder Past Stand

Every successful run lands In Review; no verdict-aware transition, so a validator changes-requested just sits for a human to drag back. Intentional for now (ah-gs7 human-driven handoff) but user asked for it. Build opt-in loop: parse validator verdict (needs machine-readable verdict), on changes-requested move card back to Ready under coder/fix role with the review as context. Ties into Stage 4 (ah-0ge).

DECIDED 2026-07-18 (user): dedicated FIXER role. Generalized routing design:
- task_types.<t> gains on_success: <type> and on_changes_requested: <type> (target is a TASK TYPE name; validated at config load).
- Routing = swap board label type:<old> -> type:<target> (Vikunja label API, lookup by title), move card to Ready, comment 'routed to <type> (round n/cap)'. Label-swap failure -> fall back In Review + warn comment.
- Verdict channel: first line of .task/summary.md must be 'Verdict: pass' or 'Verdict: changes-requested' (case-insensitive). Parsed into RunSummary.Verdict. Missing/absent verdict = pass-equivalent (lands In Review as today).
- changes-requested + on_changes_requested set -> route; pass/none + on_success set -> route; otherwise In Review (current behavior). Failure paths unchanged.
- Loop guard: per-task auto_routes counter persisted in store, incremented on EVERY automated route (both edges); config routing.max_auto_routes default 4 (design->review->fix->review = 3). At cap -> In Review + 'routing cap reached' comment. Human manual relabel+Ready still works past cap.
- New prompts/fixer.md (address ## Review findings on same branch); validator.md updated to mandate the Verdict first line.
- Intended live pipeline: design --on_success--> review --changes-requested--> fix --on_success--> review --pass--> In Review (human).

DESIGN PROPOSAL (held for user sign-off — changes the core reconcile state machine; not live-verifiable while pushes/deploy are blocked).

Now unblocked by ah-tz0 (.task/summary.md exists). Proposed:
1. MACHINE-READABLE VERDICT: don't parse free-text. Have the validator write a structured line the daemon can key on — e.g. a first line 'Verdict: pass' | 'Verdict: changes-requested' in .task/summary.md (update prompts/validator.md + validate skill), and add a domain field Verdict (parsed in runner.Summary, empty for non-validator roles).
2. OPT-IN CONFIG: task_types.review gains 'on_changes_requested: <bucket|role>' (default: none = current behavior, lands In Review for a human). When set e.g. to role 'coder', a changes-requested validator run moves the card to Ready under that role instead of In Review, carrying the review as context (the ## Review is already on the branch).
3. LOOP GUARD: reuse the delegation generation cap (max_generation) or add a review_rounds cap so design->review->coder->review can't cycle forever. A 'pass' verdict always lands In Review (human ships it).
4. STATE MACHINE: this is a new transition in internal/reconcile (finalize path) + internal/domain/transitions.go. Cover with reconcile_test.go (injected clock/fakes) AND an e2e flow before shipping.

Open questions for user: (a) auto-loop to 'coder' or a dedicated 'fixer' role? (b) opt-in per task_type (proposed) vs global? (c) cap value / mechanism. HOLDING until answered.