Subagent model override silently ignored; TUI shows a third, stale model

### Summary

Three different answers for "which model is my subagent running?":

1. **Requested** via the Agent tool's `model` parameter: `fable` (3 agents) and `sonnet` (2 agents)
2. **Displayed** in the TUI subagent view header: `Opus 4.8`
3. **Actually served**, per each agent's task-output transcript: `claude-opus-5` — all five

So the `model` override is silently ignored, and the label shown is a third value that matches neither. Both symptoms appeared immediately after the `opus` alias was remapped from Opus 4.8 to Opus 5 (2026-07-25), which suggests one incomplete rollout rather than two unrelated bugs.

### Environment

- Claude Code 2.1.220
- macOS 26.5.2 (Apple silicon)
- Session model: Fable 5
- Subagents dispatched via the Agent tool with an explicit `model` parameter, `subagent_type: "general-purpose"`

### Steps to reproduce

1. From a session, dispatch subagents with an explicit model override, e.g. `Agent({ subagent_type: "general-purpose", model: "sonnet", prompt: "..." })`, and a second one with `model: "fable"`.
2. While they run, open the subagent view in the TUI and read the model shown in the header.
3. After they finish, inspect the model recorded on the agent's own assistant turns:
```
grep -o '"model":"[^"]*"' | sort -u
```

### Expected

- The subagent runs on the requested tier, or the call fails / warns if the override cannot be honored.
- The TUI header shows the model that is actually serving the subagent.

### Actual

- Every subagent ran `claude-opus-5` regardless of the requested alias — verified across 5 agents; in one sampled transcript the field appeared on **35 of 35 assistant turns**, alongside genuine `stop_reason` and usage data, so it reflects the serving model rather than a display string.
- The TUI subagent view header read `Opus 4.8`, which matched neither the request nor the transcript.
- No warning, no error, no indication anywhere in the session that the override had been dropped.

### Impact

The silent no-op is the costly part. Model selection per subagent is how a session controls both spend and rigor — cheap breadth-first agents for mechanical search, a stronger model for adversarial verification and for security-sensitive diffs. When the parameter is accepted and then ignored:

- Cheap fan-out work silently runs on an expensive tier (unplanned spend).
- Deliberate escalations silently run below the intended tier (weaker review than believed).
- The session plans around a capability it does not have, and has no way to notice — the only route to the truth was grepping raw transcripts, because the one surface that reports a model, the TUI, was showing a stale value.

If an override cannot be applied (deployment policy, agent-type definition, alias remap), surfacing that once at dispatch time would be enough to make the behavior safe.

### Suggested fixes

1. Honor the `model` parameter, or return a visible warning naming the model that will actually run.
2. Update the TUI subagent header to the serving model (the stale "4.8" label looks like a display string not updated with the alias remap).
3. Consider a documented way to read a subagent's actual model without parsing transcript JSONL.

Start by reproducing the Agent calls with explicit sonnet and fable model parameters, then compare the task-output transcript's recorded model with the TUI subagent view header. Trace model selection from the Agent tool dispatch through the subagent view and the opus alias remap. Done means the requested model is served or a visible warning identifies the actual model, and the TUI shows that serving model.

Written by the indexing model from the issue text.