[Bug]: Fresh-session scheduled runs in a thread the user also chats in move the conversation to a context-free session #36087

Before submitting

• I searched existing issues and did not find a duplicate. (Nearest: [Bug]: A fresh-session schedule stops dispatching for good once a previous run's session still has background work #32100 and [Bug]: schedule_task silently drops freshSession when updating an existing task #32258, both closed and about different failures.)
• I included enough detail to reproduce or investigate the problem.

Area

Server, scheduled tasks

Steps to reproduce

1. In an existing Claude thread with a long conversation, create a schedule bound to that thread with freshSession: true (for example interval, every 30 minutes).
2. Let one scheduled run happen.
3. Send a normal message in the thread.

Expected behavior

The user's conversation continues in its own session, and the scheduled run gets fresh context for its own message only. Alternatively, schedule_task warns or refuses when a fresh-session schedule is bound to a thread that has user messages, and the docs say the thread will move to the new session.

Actual behavior

Each scheduled run creates a new provider thread, and ProjectionStore sets the thread's activeProviderThreadId to it. The user's next message goes to the newest session, which has no context. It answered a catch-up request by saying its only job was the scheduled check. Meanwhile, delegated-task continuations kept going to the old session, so the thread effectively had two sessions answering in turn. One thread had about 20 Claude sessions in 20 hours.

Impact

The thread loses its working context without warning, and replies contradict the visible history. In the provider event log the session switches with every run. Combined with #20339, a wake continuation can also land on the wrong provider thread.

Version or commit

0.1.9 (desktop service). Code references from main at f939f66705: ScheduledTaskService.ts sends bound fresh-session runs with freshContext: true, and ProjectionStore.ts overwrites active_provider_thread_id on each provider-thread update.

Environment

macOS, Claude CLI driven by claudeAgent through a pool provider instance, full-access thread.

Investigated with AI assistance (Claude and Codex); I checked the evidence and the code references myself.