Clearly show the subagent model and let user change it on the fly

[matkara]

Context

1. When looking at a subagent execution, it is not shown which model was triggered.
2. Once the subagent has started, it is currently not possible to change the running model.

Purpose
P0: Clearly chow the model under execution
P1: Provide the same model switch as the (root) parent agent to all subagents. The user should be able to assign any model to a subagent without aligning the subagent's model on the parent's one

[argszero]

Both halves of this are now a plugin, because both land on a public seam.

@argszero/cordis-plugin-subagent-model (source) mounts on the agent/request waterfall and rewrites the resolved LlmCallConfig of every in-process subagent request — any Agent whose session.header.delegationDepth >= 1:

• P0 (show it) — each child transcript gets one durable session event naming the route that child runs on, and a later route change adds the boundary notice (assistant turns above this point were generated by <prev>; the session continues with <new>), mirroring the loop's own wording.
• P1 (change it on the fly) — a subagent_model tool (get / set) reads and writes the selection. It is resolved per request, not per run, so a child already running follows a change from its next step. set from a subagent is refused: the selection is deployment-wide, so a child silently re-routing its siblings is not a privilege the report asked for.

npm install @argszero/cordis-plugin-subagent-model

then mount its cordis.patch.yml as a bundle patch (or add the subagent-model row by hand). With empty config it only observes — nothing is re-routed, and the sole effect is the per-child route notice. announce: false routes silently.

Why this seam and not AgentOptions

agentOptions at delegation time is per-child but fixed for the whole run. agent/request returns the LlmCallConfig the loop is about to dispatch, so rewriting there is the only point where a route can change after the child started — and installModelSelection already overwrites provider/model on that same waterfall per agent, so this is the seam the harness itself uses, not a side channel.

Boundaries I did not paper over

• In-process children only. subagent-codex, subagent-acp, subagent-claude-code and subagent-dsh-sdk run the child out of process; there is no agent/request in this process for them, so their route is untouched by construction.
• One selection for all subagents in 0.1.0 — per-child targeting is deliberately not here. The report asks for a subagent route, not for a roster.
• A route change that names no reasoning effort clears the inherited effort, mirroring resolveChildAgentOptions (the effort belonged to the route that carried it). Worth an argument if you'd rather it persisted.
• The notice is a real user-role session event, visible to the child model as well as to you; that is exactly what makes it survive resume. If a UI-side projection is the better home for it, say so — that is a different seam (session/event is emit-only, so the projection path is the client, not a plugin).

Verification

40 local tests against a real cordis context (real injection, real waterfall dispatch) plus the real dsh-tools schema validation. The declared range is probed, not assumed: scripts/probe-lines.mjs installs the published harness packages into a clean project per admitted line, asserts the five imported packages resolved to exactly the probed version before the suite runs, then runs the same suite — 24/24 on 0.1.2-rc.1, 0.1.3-alpha.2, 0.1.5-alpha.1/-alpha.2/-rc.1/-rc.2 and 0.1.6-alpha.1/-alpha.2. Harness packages are peers throughout, so no nested copy of the runtime can be installed.

Feedback welcome — particularly on per-child targeting (is a roster wanted, or is a single subagent route the right default?) and on whether a route notice belongs in the transcript at all.