fix: signal active containers to close when a scheduled task is enqueued

[aoberoi]

Type of Change

• Skill - adds a new skill in .claude/skills/
• Fix - bug fix or security fix to source code
• Simplification - reduces or simplifies source code

Description

Fixes #293. This is equivalent to Option A in that issue. I believe this is the cleanest way to fix the issue. Option B would screw up the workflow for scheduled tasks with context_mode: group, since a parallel container trying to resume a currently active session is going to lead to undefined outcomes. The single container per group invariant is worth preserving. Option C doesn't really provide any benefit if both idleWaiting and processing containers can correctly handle resuming sessions.

Also fixes a race condition (#320 (comment))

When a scheduled task was enqueued for a group with an active container, it would sit in pendingTasks until the container exited naturally — up to 30 minutes (idle timeout), or indefinitely if users kept resetting it.

Now writes the _close sentinel immediately when queuing a task against an active container. The container winds down after its current query, drainGroup fires, and the task runs in a new container within seconds.

I did some investigation to make sure the two kinds of scheduled tasks (context_mode: isolated and group) are considered. Here are all the scenarios:

Scenario 1: Container is idle, isolated task fires

• Container already emitted the between-query session update marker before
  going idle → sessions[group.folder] = "session-A" is current
• _close written, container exits from waitForIpcMessage immediately
• drainGroup runs isolated task with sessionId = undefined → creates fresh
  "session-B" → discarded by scheduler
• sessions[group.folder] is still "session-A"
• User's next message: resumes "session-A" correctly ✓

Scenario 2: Container is busy (mid-query), isolated task fires

• _close detected by pollIpcDuringQuery, stream.end() called
• Current query runs to completion, emits OUTPUT_MARKER with newSessionId →
  wrappedOnOutput updates sessions[group.folder] = "session-A" (or a new turn
  ID)
• Container exits (note: closedDuringQuery = true means it skips the
  between-query session update marker, but the result OUTPUT_MARKER already
  updated sessions)
• drainGroup runs isolated task with sessionId = undefined → fresh session,
  discarded
• User's next message: resumes "session-A" correctly ✓

Scenario 3: Container is idle, group task fires

• Same session preservation as Scenario 1
• Group task runs with sessionId = "session-A" — resumes and extends that
  session
• Scheduler discards newSessionId returned from the task — but since resuming
  doesn't create a new session ID, this is fine
• User's next message: resumes "session-A", which now includes the group
  task's turns ✓

Scenario 4: Container is busy, group task fires

• Same as Scenario 2 — current query completes, sessions[group.folder]
  updated
• Group task runs resuming that session, extends it
• User's next message: resumes correctly ✓

For Skills

• I have not made any changes to source code
• My skill contains instructions for Claude to follow (not pre-built code)
• I tested this skill on a fresh clone

[longregen]

Please clean the commit history before creating a PR: 8c1cad8 and dc4a443 don't seem relevant for the purpose of the PR.

[aoberoi]

@longregen whoops! good catch

[aoberoi]

cleaned the commit history

[aoberoi]

Found another related issue in my testing. Scheduled tasks can sometimes fire more than once because of a race condition. The race is between the SCHEDULER_POLL_INTERVAL (60s) and the execution time of a task (which can take longer than 60s).

The solution I'm working on is to add a new "running" state to a task, and make sure the scheduler doesn't pick up running tasks to run on the next scheduler poll interval. There was an alternative approach, to just mark the status = NULL, but I prefer this solution because its explicit (which can help for inspecting issues in the system) and we can actually implement scheduled task recovery if there's an unexpected crash.

The fix includes all the state transitions to make this work and some tests.