[Bug] Follow-up can remain indefinitely queued during driver retirement

[EonHao]

Summary

A waking Agent.followup() can be accepted into next-turn but never run when it arrives after the turn loop's final inbox check and before the driver commits idle. The agent then reports idle while holding pending user work. Another unrelated waking message is required to resume it.

Tested on master at commit 47f943859bef60e4160492346772ded9b24f765a, including a real deepseek/deepseek-v4-pro-0813 AgentLoop run through OpenRouter and the real Bash tool.

Reproduction

1. Start an agent and let its first turn reach turn/end.
2. From a microtask scheduled by the turn/end observer, call:

queueMicrotask(() => {
  agent.followup(createUserMessage({
    content: [{
      type: "text",
      text: "Use bash to write RETIREMENT_FOLLOWUP to retirement.txt.",
    }],
    source: { kind: "user" },
  }));
});

Scheduling outside the synchronous session/event callback is necessary because nested session appends are intentionally rejected.

3. Await agent.whenIdle() and wait another 500 ms.
4. Inspect status, inbox, turn count, and the filesystem.

Observed:

agent.status: idle
agent.inbox.nextTurn.length: 1
turn/start count: 1
retirement.txt: absent

After sending a second, unrelated followup(), the parked request runs, retirement.txt contains RETIREMENT_FOLLOWUP\n, and the second message opens a third turn.

The deterministic run reported:

{
  "strandedWhileIdle": true,
  "pendingNextTurnWhileIdle": 1,
  "recoveredOnlyAfterSecondWake": true,
  "finalTurnCount": 3
}

Expected behavior

A waking message accepted before the current driver retires should either be claimed by that driver or latch a replacement driver. An idle agent should not retain waking next-turn work indefinitely.

Root cause

wakeDriver() returns for a live non-idle phase without setting wakeRequested; it only latches maintenance and post-abort wakes.

The loop's last pending-work check and the subsequent driver retirement leave a window in which work is inserted, its wake is ignored, and the driver transitions to idle without rechecking the inbox.

The repository already documents the same retirement-window hole for job completion notices and steering. This reproduction shows that ordinary user follow-ups share the same path and impact.

Impact

• A user message can appear accepted but receive no response.
• The agent reports idle while waking work remains pending.
• Background completion notices and steering are affected by the same core state transition.
• Recovery depends on an unrelated later wake.

Suggested fix

At the retirement boundary, atomically publish idle and then recheck pending waking work, or latch any waking send that arrives after the driver's final claim opportunity.

A regression test could schedule followup() in a microtask from turn/end, assert that the agent never remains idle with pending waking work, and verify that no second external wake is required.