CC/MCP scheduled tasks silently fire on Opus 5 despite claude-sonnet-5 configured default

Scheduled tasks created via create_scheduled_task (CC/MCP surface) have no live model field — the model is bound at a server-side pin, not the org/session's configured default (settings.json → claude-sonnet-5, confirmed correctly set on our side).

Canary evidence (session-metadata read via get_session, 2026-07-26, 6 sampled fires):

| Task | Fired (UTC) | Model |
|---|---|---|
| ora-aaos-publish-contracts | 07-25 19:07 | claude-opus-5[1m] |
| ora-pm-ledger | 07-25 22:09 | claude-sonnet-5 |
| ora-health-guard | 07-26 14:58 | claude-sonnet-5 |
| ora-aaos-expire-leases | 07-26 14:58 | claude-opus-5[1m] |
| ora-aaos-publish-contracts | 07-26 15:00 | claude-opus-5[1m] |
| ora-override-sweep-dryrun-check | 07-26 15:53 | claude-opus-5[1m] |

4 of 6 fires landed on Opus 5, not the configured Sonnet default. Notably the same task (ora-aaos-publish-contracts) hit Opus 5 on two separate fires, while other tasks with no special configuration landed on Sonnet — indicating the pin is non-deterministic per-session, not a fixed per-task assignment. We first caught this pattern 2026-07-08 (then pinned to claude-opus-4-8); the rollout to Opus 5 just reproduced the same gap under a new model id.

Impact: routine/low-complexity scheduled automations silently bill at Opus rates with no way to detect it except manual transcript/session-metadata canaries after the fact, and no way to fix it — there is no model parameter exposed on create_scheduled_task / update_scheduled_task to pin the fleet to a chosen tier.

Ask: either (a) honor the account/org-level default model for CC/MCP scheduled-task execution, or (b) expose a model field on create_scheduled_task/update_scheduled_task so it can be set explicitly per task, matching how the LAMS/Cowork scheduled-task surface already behaves (model is set at creation and stays put there).