Scheduled runs far in the future should start in a fresh thread by default

[lukemaj]

Problem

schedule_task binds runs to the calling thread by default, and the tool guidance tells agents to keep that default ("runs post into THIS thread by default, which suits an orchestrator"). That's right for short timers, but agents also use it for one-off checks hours ahead ("verify the deploy at 19:15"). When such a run fires, the provider reloads the whole thread with a cold prompt cache. Provider caches last at most an hour, so a check scheduled hours out from a long thread pays a full uncached reload of everything. In my case that was a ~430k-token thread for a check whose prompt was already self-contained.

Proposal

• Default by timing: when bindToCurrentThread is omitted, bind to the calling thread only when runs are close together: a once run due within ~55 minutes, or an interval of ~55 minutes or less. fixed_time, weekly, longer intervals and later once runs default to a fresh thread. webhook keeps today's default, since its timing is unknown and an orchestrating thread often dedupes triggers.
• Explicit choice still wins: bindToCurrentThread: true keeps binding when the agent knows its thread will still be active, for example while it is coordinating live work.
• Guidance: tell agents that a fresh-thread run needs a self-contained prompt (links, exact commands, where to report), and to bind to their own thread only when it will still be active.

No new setting or schema change; it's a default and two guidance strings.

Alternatives considered

• Threshold on thread size instead of timing: needs per-provider context accounting, and timing alone predicts a cold cache.
• Guidance only, no default change: weaker, since agents follow the tool's default.

I'm trying this in a fork first (toolboxmd/chromeria#521) and happy to share results or open a PR if you want this direction.