spawn_task chips inherit the spawning session's pinned model instead of defaulting to the user's configured default

Observed behavior: When a session running on a pinned/overridden model (e.g. a scheduled task with model: claude-opus-4-8 in its frontmatter) calls the spawn_task MCP tool to flag out-of-scope work as a background chip, the resulting spun-off chip session runs on that same pinned model (Opus) rather than falling back to the user's account-level default model ("model": "sonnet" in ~/.claude/settings.json).

Expected behavior: A chip spun off via spawn_task should default to the user's configured default model, independent of whatever model the spawning session happened to be running on. Chip work is typically scoped follow-up, not the deep-reasoning task the parent session was pinned for.

Why this matters: There's no way to control this today — spawn_task takes no model parameter, and no settings.json field governs chip-launch model resolution. Users who deliberately pin heavier models for specific automations (for good reason — e.g. an adversarial code reviewer, or an unattended bug-fixer) have no way to keep spun-off follow-up chips on a cheaper tier. This silently multiplies spend on work that was never meant to run on the expensive tier.

Suggested fix: Either (a) have spun-off chip sessions always resolve to the effective settings.json/account default model rather than inheriting the spawning session's active model, or (b) add an explicit model parameter to spawn_task so a session can request a specific tier for the chip it creates.