agent-lifecycle: bound ensureAwake so a hung wake can't wedge a workbench silently forever

[TheGreatAxios]

Summary

CL-6643: a message POST was accepted, then silently swallowed — no fanout log, no wake attempt, no error, no undelivered notice — for a workbench whose agent's run had no sidecar-side deployment record (parked aside, cold wake required).

The prime suspect in the ticket was PR #298's wireHash drift-reconcile logic in packages/chat/src/platform-adapter.ts. That turned out not to be the mechanism: the drift-reconcile path (reconcileDriftedRun) already catches and logs on failure and proceeds ("nothing to reconcile") rather than swallowing, and wakeByAddress's branches all throw or delegate rather than early-returning silently.

The actual mechanism is in packages/agent-lifecycle/src/index.ts's createAgentLifecycle. ensureAwake coalesces concurrent callers for the same address onto one in-flight wake() call via a pendingWakes map, releasing the entry in a .finally() once wake() settles. But nothing bounded how long wake() could take — a cold wake for a run with no sidecar record is a real deploy round-trip to the host, and if that round-trip never acks (confirmed live: reproduced by sending fresh messages into the broken run_d661612… workbench — POST accepted every time, then permanent silence, no fanout/wake/error/undelivered-notice lines ever), the wake() promise never settles. Its .finally never runs, so the address is wedged in pendingWakes forever: every later ensureAwake call for that address — i.e. every future message sent to that workbench — coalesces onto the same dead promise and hangs too, for the rest of the process's life, with nothing ever rejecting for sendMail/dispatchTurnBatch to turn into an undelivered notice.

Fix

ensureAwake now races the injected wake port against a new wakeTimeoutMs option (default 30s) via wakeWithTimeout, and always settles — clearing the address out of pendingWakes on either outcome. A wake that never acks now rejects instead of hanging, which dispatchTurnBatch's existing catch already turns into a real undelivered notice on the timeline.

Test plan

• Added a red test (packages/agent-lifecycle/test/index.test.ts) reproducing the swallow: a wake that never settles must not permanently wedge the address — a first call rejects on timeout, and a second, later call for the same address gets its own fresh wake attempt rather than coalescing onto the dead promise. Confirmed this test hangs (no output, timeout-killed) against the pre-fix code.
• WORKBENCH_CHECK_SINCE=origin/main bun run typecheck — pass
• WORKBENCH_CHECK_SINCE=origin/main bun run test — pass (198 tests across affected packages, including the new one)
• bun run lint — pass (0 errors)
• Reproduced live against the running dev stack (wb_verify_0822, workbench run_d661612…): sent a fresh message ("Third wake check...") into the already-broken workbench; POST accepted (201), then confirmed the exact same permanent silence the ticket describes, with no fanout/wake/error lines at all — matching the mechanism above.
• Live send → typing indicator → real reply on run_d661612… with this fix loaded: not done. The fix lives in this worktree; the shared dev stack (.worktrees/cl-e2e-main, log e2e-final4.log) is running the pre-fix code from its own checkout, and other work depends on it staying up, so I did not restart it to load this branch. Whoever picks this up for review should restart that stack (or a fresh one) on this branch to confirm the end-to-end cold-wake-then-reply path.