Configure worker and supervisor models per workflow stage #13

What & why

I want to choose which model the worker and the supervisor use at each stage, for example a cheaper, faster model for Task and QA, a stronger one for Design and Code, and a different model supervising than working. Today the choice is one model per role for the whole run. Stages differ a lot in difficulty and in how many tokens they use, so per-stage choice would cut usage without weakening the stages that matter.

Acceptance criteria

• A workflow node can override the model for each role, for example workflow.nodes.design.agents.worker.model and workflow.nodes.qa.agents.supervisor.model. Anything unset inherits the run-wide agents.worker.model / agents.supervisor.model, then the harness default.
• Validation rejects unknown keys. Configurations without overrides keep their configuration digests, so existing runs are unaffected.
• The effective model per stage and role is visible before and during a run: envctl run validate, run show / run readiness (next to the per-node limits), and the dashboard.
• Each attempt records the model it actually ran. Token usage is attributable per stage and model, so cheaper choices show up in the run's totals.
• Steering resumes and stall nudges keep the model of the generation they resume. Readiness probes use the cheapest configured model for their role, or a documented choice.
• Documented in the config reference, including that agents.*.model already exists run-wide.

Context

• Today: workflow.Harness.Model (internal/workflow/config.go) is set once per role under agents. It's copied into every worker and supervisor invocation (internal/localexec/attempt.go) and into readiness probes (internal/localexec/backend.go), and passed as --model by both adapters (internal/agent/claude.go, internal/agent/codex.go). It isn't documented in config-reference.mdx.
• Precedent: per-node overrides already exist for limits (workflow.nodes.<id>.limits via Config.NodeLimits), a pattern this could follow.
• Motivation from dogfooding: unset, Claude runs used the harness default, claude-sonnet-5, for the main work. A single run reached 11.7M–28.1M tokens ($6.65–$14.58 API-equivalent) against the new limits.run_tokens ceiling.
• Open questions:
  • Should a node also be able to override the harness (kind), for example Codex for Code and Claude for review?
  • Should the prompt tell the supervisor which model produced the work?