Make the orchestrating session the single dispatcher of verify-task

[Copilot]

Three skills disagreed on who dispatches verify-task, and execute-task (itself a subagent) was told to dispatch it — impossible on Claude Code, where a subagent cannot spawn another subagent. The result was either self-verification inside the implementer's context (defeating the independence the design exists for) or a mid-chain stall.

Control-flow model

• The orchestrating session (whatever loaded start-ritus, including ticket-review / address-feedback / debug) owns every dispatch in the execute → verify → re-verify loop.
• Dispatched subagents (execute-task, verify-task, pr-review) return a report and never dispatch further subagents.
• verify-task's Subagent dispatch instructions is now the single source of truth; every other skill references it.

Changes

• execute-task — dropped the "Dispatch verify-task subagent" process step and its ## Next restatement; the executor returns a report.
• verify-task — marked as the canonical description of the dispatch loop.
• ticket-review (+ templates/task-files.md) — orchestrating session dispatches verify-task after each execute-task returns, instead of "each execute-task dispatches its own verify-task".
• pr-review — Request-Changes fix loop reports findings back rather than dispatching execute-task / verify-task / pr-review from within the subagent.
• address-feedback — clarified it runs in the orchestrating session and that execute-task returns a report.
• start-ritus — stated that only the orchestrating session dispatches; removed the contradictory address-feedback row from the Subagent configs table (it is an orchestrator, not a dispatched subagent).

Out of scope

The issue also suggested raising the verifier's model tier above haiku. Left unchanged — it is not an acceptance criterion, and the gate's value comes from an independent clean context rather than raw model strength; a tier change is an explicit design call for maintainers.