Revert "feat(models): move the implementer to opus/high"

This reverts commit cdbc2d0. The bump was a judgment call without
evidence, and the planner design intent argues the other way: the plan
Iron Law is "EVERY STEP THAT CHANGES CODE INCLUDES THE CODE" and tasks
are sized so a subagent executes one "without judgement calls outside
its remit" (planner/SKILL.md) — the planner exists precisely to remove
design latitude from the implementer, which points at sonnet, not opus.
opus is only justified to the degree real plans leave slack (RED-step
invention, tree reconciliation, review repair), and that slack is
measurable, not felt. Restore sonnet/high; a future bump should be
grounded in the loop metrics (spec re-loop count, quality
changes_requested rate, end-verify BLOCKED rate) via postmortem, not a
gut call. The four fable gates (b591e75) are untouched.

docs/agent-template.md

@@ -137,18 +137,9 @@ Assignment rule, in priority order:
    evidence, the in-loop quality review) — run `opus`. Opus is
    the documented strength for code review, debugging, and deep
    reasoning.
-3. **Mechanical scope** — recon, extraction, compliance-diffing
-   run `sonnet` (near-opus quality on tightly-scoped work at
-   lower latency and cost). Plan execution itself — the
-   `implementer` — is owner-ratified (2026-07-20) onto `opus`:
-   authored code is the pipeline's primary output, so it takes
-   the judgment model, but pairs it with `high` effort, not
-   `xhigh` — it is the most-dispatched in-loop role, and
-   volume × wall-clock (rule 4) still governs its thinking
-   budget. The compiler-driven-edit arm keeps dispatching the
-   implementer agentType at `sonnet`/`high`: compiler-enumerated
-   propagation is mechanical, and that arm's policy header pins
-   its own tier.
+3. **Mechanical scope** — tightly-scoped execution of a pre-made
+   plan, recon, extraction, compliance-diffing run `sonnet`
+   (near-opus coding quality at lower latency and cost).
 4. **Volume × wall-clock** — agents dispatched per-task inside
    loops or fanned out in parallel swarms multiply their model's
    latency; they run `sonnet` unless rule 2 overrides (currently
@@ -165,9 +156,9 @@ Assignment rule, in priority order:
 
 Current distribution: `fable` — architect, debugger,
 grounding-check, tdd-author. `opus` — bencher, fieldtester,
-implementer (at `high`), plan-recon, quality-reviewer,
-spec-skeptic. `sonnet` — docwriter, glossary-extractor,
-spec-reviewer, synthetic-user, tester.
+plan-recon, quality-reviewer, spec-skeptic. `sonnet` — docwriter,
+glossary-extractor, implementer, spec-reviewer, synthetic-user,
+tester.
 
 The same rule binds Workflow scripts: every `agent()` call passes an
 explicit `model:` option, and `fable` is never a valid value there —
@@ -183,16 +174,14 @@ effort, coupling every dispatch's thinking budget to whatever the user
 happens to be chatting at — the same session-state coupling the `model`
 pin exists to remove. Effort follows the model split:
 
-- **`xhigh` on every `fable` and `opus` judgment agent.** The
-  judgement roles are the pipeline's quality floor; their thinking
-  budget must not silently degrade because the session runs lower.
-  The fable gates deliberately stay at `xhigh`, not `max` — the
+- **`xhigh` on every `fable` and `opus` agent.** The judgement
+  roles are the pipeline's quality floor; their thinking budget
+  must not silently degrade because the session runs lower. The
+  fable gates deliberately stay at `xhigh`, not `max` — the
   marginal thinking is not worth the extra latency and
-  scarce-budget burn. One `opus` agent is exempt: the
-  `implementer` pairs `opus` with `high` (§ model rule 3 — the
-  most-dispatched in-loop role keeps the in-loop effort tier).
-- **`high` on every `sonnet` agent.** Tightly-scoped mechanical
-  work gains little from `xhigh` but pays its latency on
+  scarce-budget burn.
+- **`high` on every `sonnet` agent.** Tightly-scoped execution of a
+  pre-made plan gains little from `xhigh` but pays its latency on
   every dispatch — and these are exactly the roles dispatched
   per-task inside loops (wall-clock is the pipeline's efficiency
   metric). Not lower than `high`: a sloppy in-loop step triggers