[BUG] TUI model badge for background subagents shows the session model, not the resolved override

Preflight Checklist

• [x] I have searched existing issues and this bug hasn't been reported yet
• [x] This is a single bug report (not multiple bugs)

Environment

• Claude Code v2.1.206, macOS (darwin, arm64)
• Session main model: claude-fable-5[1m] (set via /model, saved in settings.json)

Description

A background subagent launched via the Agent tool with an explicit model override (model: "opus", subagent_type: "general-purpose", run_in_background: true) runs the pinned model correctly at the API level, but the TUI's task/agent view badges the running agent with the session model ("Fable") instead of the resolved model.

The override is genuinely honored: the task's JSONL transcript stamps every assistant message with the resolved model. In my run, 29 of 29 assistant messages carry "model":"claude-opus-4-8", a one-to-one match with the assistant-message count, while the TUI displayed the agent as Fable for the whole run.

Steps to Reproduce

1. Start a session whose main model is not Opus (e.g. claude-fable-5).
2. Have the main loop call the Agent tool with model: "opus" and run_in_background: true.
3. Open the task/agent view in the TUI and note the model badge on the running agent: it shows the session model (Fable).
4. Extract the ground truth from the task transcript: grep -o '"model":"[^"]*"' <task output file> | sort | uniq -c shows only claude-opus-4-8.

Expected Behavior

The badge shows the subagent's resolved model (claude-opus-4-8).

Actual Behavior

The badge shows the parent session's model (claude-fable-5), so a correctly pinned agent looks like a failed override. The only way to verify the real model is to grep the transcript JSONL outside the TUI.

Impact

Users conclude the model override silently failed and burn time re-verifying or re-spawning agents. With premium session models the badge also misreads as an unintended cost escalation (or masks a real one). Given #75054 / #74591 / #68147, where pins ARE genuinely dropped on resume, a trustworthy badge is the natural way to notice those bugs, and today it cannot be trusted in either direction.

Related (not duplicates)

• #76055 requests showing the resolved model/config in the subagent detail view (feature); this report is about the existing badge showing a wrong value.
• #75054, #74591, #68147 cover the pin being genuinely dropped on continuation/resume; here the pin is honored and only the display is wrong (initial run, no resume involved).