[FEATURE] Model selection when spawning a background task chip

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

When a background task chip (the mcp__ccd_session__spawn_task suggestion) is accepted and spun off into its own local session + worktree in the Claude Code desktop app, there is no way to choose which model the new session runs on. It silently inherits the configured default (the settings model field, else the plan default).

This is a problem because spawned task sessions are frequently a different kind of work than the parent session that flagged them:

• A quick mechanical cleanup flagged mid-Opus-session would be perfectly fine — and cheaper/faster — on Sonnet or Haiku.
• Conversely, a flagged security issue or cross-layer bug may warrant Opus even if the parent session was running a cheaper tier.

Today the only recourse is to open the spawned session and run /model manually after it starts, which undercuts the "one click and walk away" value of task chips.

Proposed Solution

Allow the model to be chosen at chip-accept time. Either (or both) of:

1. Model picker on the task-chip UI — a dropdown on the chip (defaulting to the inherited/default model) so the user can pick the tier before the session spins up.
2. Optional model hint on spawn — let the suggesting session pass an optional model parameter via spawn_task, surfaced editably on the chip, so the agent that flagged the work can hint the appropriate tier.

Alternative Solutions

Current workaround: accept the chip, open the spawned session, and run /model <name> manually before doing any real work. This requires remembering to do it every time and wastes the unattended-spawn benefit. Setting a global default model in settings doesn't help because the whole point is that different chips want different tiers.

Priority

Low - Nice to have

Feature Category

Interactive mode (TUI)

Use Case Example

1. I'm in an Opus session doing a complex refactor.
2. Mid-task I notice an unrelated stale doc and a separate possible security issue; both get flagged as task chips.
3. I want the stale-doc fix to run on Haiku (trivial, cheap) and the security investigation to run on Opus (warrants the strongest model).
4. With this feature I'd set each chip's model before spawning, instead of opening both sessions and running /model by hand.
5. This saves time and avoids accidentally running cheap work on an expensive tier (or vice versa).

Additional Context

Related: #65586 (programmatic model switch for an already-running session) — complementary but distinct: that request is about switching a live session's model via an API; this is about selecting the model at spawn time for a chip-created session.