[BUG] Subagent view renders the main session's model/effort/agent identity instead of the subagent's (header, thinking indicator, agent list)

Summary

When you drill into a spawned subagent's view, the UI chrome renders the main session's identity — model, reasoning effort, and agent definition — instead of the subagent's own resolved values. This shows up as three symptoms on three surfaces, but they share one root: a subagent's resolved runtime identity is never threaded into the chrome that renders while its view is focused.

Filing as one issue because the three existing reports below each treat a single surface, and fixing them independently would mean three patches over one missing piece of state.

Repro

1. Run a main session on model A with effort X (e.g. Fable 5, low effort) using the default agent.
2. Spawn a subagent that resolves to a different identity — different model, different effort, and a custom agent definition (e.g. Sonnet, medium effort, a custom agent from .claude/agents/).
3. Open that subagent's view (ctrl+o, or via the backgrounded-agent manage list).

Expected vs actual

| Surface | Expected | Actual |
|---|---|---|
| Thinking indicator, inside the subagent's view | The subagent's effort | The main session's effort |
| View header (scroll to top) | The subagent's model, effort, agent definition | The main session's — the header does not change at all |
| Spawned-agent list | Agent name + its model/effort | Agent name only |

What is and isn't already filed

• #76055 — [FEATURE] Show subagent model and config in subagent detail view. Covers the header/detail-view surface, framed as missing info.
• #76319 — [Bug] Subagent displays incorrect model version in panel. The panel showing a wrong model (a Fable 5 subagent displayed as Opus 4.8) — same root, different surface.
• #77367 — Show the model powering each subagent task in the task display and /tasks list. Covers model in the list, but not effort.

Not covered by any of the above:

1. The thinking indicator renders the main session's effort level. This is a wrong-value bug, not absent info — the UI actively states an effort the subagent is not running at, which is worse than showing nothing because it reads as authoritative.
2. Effort in the agent list. #77367 asks only for model.

Why it matters

Per-agent model: frontmatter, the model/effort parameters on the Agent tool, and the CLAUDE_CODE_SUBAGENT_MODEL floor all mean subagents routinely run on a different model and effort than the session that spawned them. That divergence is exactly when you drill into a subagent's view — to check it behaved as configured. Today the chrome answers that question with the main session's values, so the surface that should confirm the configuration instead silently contradicts it.

Proposed shape

Thread the subagent's resolved identity — agent definition name, resolved model (after any CLAUDE_CODE_SUBAGENT_MODEL floor or per-agent frontmatter is applied), and resolved reasoning effort — into the view state, and resolve all three surfaces from that one source:

• Thinking indicator reads the focused subagent's effort.
• Header reflects the focused subagent's model / effort / agent definition, and restores the main session's on return.
• List entries render name (model, effort) — behind a setting if the default label needs to stay terse.

Acceptance criteria

• Opening a subagent view whose model/effort differ from the main session shows the subagent's values in the header.
• The thinking indicator shows the subagent's effort, never the main session's.
• The header shows the subagent's agent definition, not the session's.
• Returning to the main thread restores the main session's values.
• List entries show the resolved model and effort (or do so when the setting is enabled).
• Resolved values reflect runtime resolution, not frontmatter as written — i.e. an env-level model floor is visible as applied.

Environment

• Version: 2.1.210
• Platform: darwin