[Bug] Persisted waking follow-up survives SIGKILL but remains idle after resume

[andrew-stelmach-fleet]

Summary

A waking Agent.followup() can be durably persisted before SIGKILL, reconstructed by agents.resume(), and then remain indefinitely queued because the resumed agent starts idle and does not restore the wake obligation.

Tested on master at 47f943859bef60e4160492346772ded9b24f765a.

Reproduction

I used two processes and the public agent/persistence APIs.

Process 1:

1. Create a persisted agent.
2. Enter a never-settling runMaintenance() so the driver cannot claim the message.
3. Call agent.followup() with survive the crash. This is a waking operation and is latched while maintenance owns the phase.
4. Flush the session so the inbox splice is durable.
5. Send SIGKILL.

Process 2:

1. Mount a fresh Context over the same persistence directory.
2. Call ctx.agents.resume(sessionId).
3. Wait 250 ms and inspect agent status, inbox, session events, and model requests.

Exact output:

{"phaseStatus":"idle","pendingNextTurn":1,"eventTypes":["agent/inbox/spliced"]}
seed_exit=137
{"loadedEventTypes":["agent/inbox/spliced"],"statusAfterResume":"idle","pendingNextTurnAfterResume":1,"modelRequestCountAfterResume":0,"turnStartCountAfterResume":0,"pendingText":{"type":"text","text":"survive the crash"}}
resume_exit=0

The message survives and reconstructs correctly, but no turn starts and no model request occurs.

Expected behavior

An accepted waking follow-up that was durably recorded before process death should eventually execute after a successful resume, without requiring a second unrelated message.

Non-waking inject() semantics should remain non-waking. A robust fix may therefore need durable wake intent, or at minimum an explicit rule that pending next-turn input wakes on cold resume.

Root cause

• Inbox correctly reconstructs pending durable splice events.
• ReactLoopAgent construction always initializes the phase as idle.
• Resume loads, constructs, sets up, and publishes the agent but never restores a wake.
• followup() is documented to queue next-turn input and wake the driver.

The current resume test covers deliberately non-waking inject() state and requires a later follow-up to activate it. It does not cover a persisted waking follow-up: resume.spec.ts.

Impact

A service restart, crash, machine reboot, or worker replacement can leave accepted durable user work parked forever while the resumed agent reports idle. The user receives no failure and recovery requires a later unrelated wake.

Acceptance criteria

• A waking follow-up durably recorded before SIGKILL runs after cold resume.
• A resumed agent does not report stable idle while such waking work remains pending.
• Non-waking injected context remains staged until an actual wake.
• Tests cover process death while a waking follow-up is pending and distinguish followup/steer from inject.

This is distinct from Discussion #274, which reports a same-process driver-retirement race. Here the process dies while the wake is validly latched and cold resume loses the wake despite reconstructing the message. It is also distinct from #167, which requests a headless CLI resume entrypoint; this reproduction uses the existing programmatic resume successfully.