feat: auto-resume idle workers with pending in_progress tasks when messaged

[komoreka]

Problem

When a worker's ephemeral session expires, it transitions to idle. If it has in_progress tasks and unread inbox messages, it stays idle indefinitely until a human manually restarts it from the desktop app. Directors have no programmatic way to trigger the resume.

This creates a gap in autonomous orchestration: a director sends a task brief → worker session times out mid-work → work stalls silently.

Proposed solution

Two complementary mechanisms:

1. Message-triggered auto-resume

When a message is delivered to an idle agent's inbox, Stoneforge should automatically attempt to start the agent's session so it can process the message. This mirrors how email clients wake up mail apps.

2. Watchdog: idle worker + in_progress task = auto-restart

A background scheduler checks for agents that are idle with tasks in in_progress or open status assigned to them, and triggers sf agent start automatically after a configurable timeout (e.g. 5 minutes).

3. (Alternative) sf message send flag

Add a --wake flag to sf message send that also starts the target agent's session:

sf message send --to el-ukb6 --content "Resume task..." --wake

Current workaround

Director must manually call sf agent start <id> — which currently also fails (see issue #61). Requires desktop app restart.

Why this matters

Orchestration sessions can run for hours. Workers going idle between tasks is expected and healthy. What's not acceptable is that re-engaging them requires human intervention. Auto-resume would make multi-worker pipelines genuinely autonomous.

[notadamking]

If it has in_progress tasks and unread inbox messages, it stays idle indefinitely until a human manually restarts it from the desktop app.

Neither of these should be true. An agent with an in_progress task will be automatically dispatched on the next dispatch cycle. Same for if an agent has unread messages, a message triage session will be spawned to triage the messages for that agent.

If this is not occurring for you, then it indicates a bug and I would need more information to understand why it is happening. A video could help.

[komoreka]

Tested on stock master from inside a Claude Code session and you're partially right — orphan recovery via --resume works, captured 3 successful "Resumed session for orphaned task..." entries. But fresh-spawn paths (sf agent start, and the daemon's first-time dispatch to a worker without a resumable session) reliably fail with "Session exited before init" on master.

That's the bug filed as #103 (CLAUDECODE inheritance). Claude's nested-session check apparently doesn't fire on --resume, only on fresh starts, which is why your tests likely worked but mine didn't — when running stoneforge from inside a Claude Code session, every fresh spawn fails, every "spawn fresh" recovery fails, only resumes succeed.

So #62 isn't really a feature gap, it's the fresh-spawn half of #103 manifesting as "auto-resume doesn't fire" because the dispatch-then-spawn pattern dies before the worker can register a session for future resume. PR #104 fixes the fresh-spawn path; once that lands, both paths work.

Closing as redundant with #103/#104, sorry for the noise.