spawn_task background sessions inherit parent session model, ignoring settings.json; no model parameter available

Summary

Sessions spawned via the session MCP tool spawn_task (background-task chips in Claude Code Desktop) always inherit the parent session's current model, ignoring both the target project's .claude/settings.json "model" and the user-level ~/.claude/settings.json "model". There is also no way to specify a model in the spawn_task call itself.

Environment

• Claude Code Desktop (macOS, Darwin 25.5.0)
• Parent session model: claude-fable-5 (switched via /model)

Steps to reproduce

1. Set "model": "opus" in ~/.claude/settings.json.
2. Set "model": "opus" in the target project's .claude/settings.json (a different directory from the parent session's cwd).
3. In a parent session, switch the model to claude-fable-5 via /model.
4. Have the agent call spawn_task with cwd pointing to the target project.
5. Click the resulting chip to start the background session.

Actual behavior

The spawned session starts with model: "claude-fable-5" (verified via the get_session metadata tool). Reproduced 4/4 times with 4 different chips across 3 different target projects — all inherited the parent's model and ignored the project/user settings.json values.

Expected behavior

Either (ideally both):

1. spawn_task accepts an optional model parameter, the same way the Agent (subagent) tool and Workflow agent() already do. It is inconsistent that in-session subagents can pin a model but spawned interactive sessions cannot.
2. Spawned sessions resolve their model from normal settings precedence (project .claude/settings.json → user settings), instead of inheriting the parent session's transient /model state.

Impact

Model tiers with strict usage limits (e.g. Fable 5 weekly caps) get burned unintentionally: an orchestrating session running on a high-tier model fans out several worker sessions that should run on Opus/Sonnet, but they all silently start on the high-tier model. The only workaround today is manually switching the model in every spawned session, or toggling the parent's model before each spawn — both error-prone.

The prompt-level workaround ("recommended model: Opus, please switch") is also unreliable: the spawned session's agent can simply decide to keep the inherited model.