Port supervisor/delegation coordination pattern from ARES

[jay-m-dev]

Context

ASAREE's factorial experiments currently vary a single agent's config per
run via create_run(..., model_config_overrides=..., pattern_overrides=...)
(runner.py) — one agent role, retargeted per cell by shallow-merging an
override dict onto its stored model_config_data at execute time. That's
sufficient for factors like model/effort/tier on one agent (the
spinal_surgery use case), and it isn't a one-off: it mirrors an idiom ARES's
own supervisor pattern already applies one level down, per delegated
sub-task rather than per top-level run.

That supervisor/delegation layer has not been ported to agentic-core:

• ares/engine/patterns/builtin/supervisor_architecture.py —
  DelegatingCoordinatorPlugin, real multi-agent delegation via
  delegate_task/get_task
• ares/schemas/patterns/supervisor.py — SupervisorSubTask (per-sub-task
  target_agent_id, pattern_overrides, model_config_override,
  dependencies for prior-result injection)
• ares/schemas/delegation.py — DelegateTaskRequest
• the delegated_task model/service backing delegate_task/get_task

See ares/backend/tests/engine/test_supervisor_override_propagation.py for
the existing, tested per-sub-task override propagation this would need to
preserve.

Why this matters for ASAREE

Today a factorial factor can only be "which model/effort/pattern does this
one agent use." If a future experiment's factors are about team
composition — e.g. "solo agent" vs. "supervisor + N workers," or "does a
critic participate" — that requires a real coordination pattern with
per-worker overrides, not just a per-run override on one agent. This is the
natural extension of the same mechanism, applied to a team instead of a
single agent.

Scope (not yet designed in detail)

• Port the supervisor/delegation pattern's engine code into agentic-core
  (patterns catalog, delegation service, delegated-task persistence)
• Preserve per-sub-task pattern_overrides/model_config_override
  propagation to worker agents
• Decide whether this becomes a first-class ASAREE-native coordination
  pattern (vs. staying notebook-orchestrated) — this was explicitly deferred
  in ARES/project_plan/core_asaree_use_case.md §10 as a follow-up study
  after the initial spinal_surgery publication, not a blocker for it

Non-goals for now

Nothing in the current spinal_surgery use case depends on this — it's
single-agent, so model_config_overrides/pattern_overrides on
create_run already covers it.