[Feature]: let update_scheduled_task (and schedule_task) set modelSelection, so agents can move a task to another provider instance #23075

Before submitting

• I searched existing issues and did not find a duplicate.

Area

apps/server (MCP orchestrator toolkit), packages/contracts

Problem

A scheduled task stores its own modelSelection (provider instance, model and options). Since #18467, a thread-bound run follows its thread's current selection, but a task that starts a new thread per run still uses the stored one. The MCP tools can't read or change it:

• update_scheduled_task accepts only prompt, title, schedule, enabled and bindToCurrentThread;
• schedule_task always inherits the calling thread's selection.

The app's own ScheduledTaskUpsertInput already carries modelSelection, so this is only missing from the MCP surface.

Our use case

We run two Claude subscription accounts on each machine as two Claude provider instances (claudeAgent and claudeAgent_claude_agt, each with its own homePath). We balance load between them and fail over when one nears its 5-hour or weekly limit.

• An orchestrating agent can do almost all of that over MCP. But each scheduled task stays on the instance it was created under, and moving it needs a person to click through Settings > Scheduled tasks on every machine.
• If they don't, every unbound task (our routines start a fresh thread per run) keeps running on the exhausted account.
• Today we work around it by pointing a machine's default instance at the other account's config dir, but that moves everything on the machine at once.

Proposal

• update_scheduled_task: an optional modelSelection (the same ModelSelection shape the app uses: instanceId, model, options). Omit it to keep the stored one, like the other fields. Validate it the way the composer does (known instance, model offered by it), and reject a selection with broader runtime access than the caller's, consistent with the existing permission ceiling.
• schedule_task: the same optional field, defaulting to today's behaviour (inherit from the calling thread).
• list_scheduled_tasks: include each task's modelSelection in the result, so an agent can see which tasks are on which instance before moving them.
• For bound tasks (which follow their thread since fix(server): thread-bound scheduled tasks run on the thread's current provider #18467), document that a stored modelSelection is ignored, or have update_scheduled_task reject one, so callers aren't misled.

Why it matters

Multi-account and multi-provider setups are what delegate_task and the provider instances are built for. Scheduled tasks are the one piece an agent can't re-point, so they become the step that fails silently during a limit.