Pace planned-restart recovery without stalling its backlog

[hamzamerzic]

Summary

• start authenticated planned-restart continuations in small per-sweep batches
• promptly drain the durable remainder while each pass makes progress
• return to the existing event/60-second cadence after a no-progress pass
• preserve the nonce, policy, latest-run, unanswered-question, and queued-app-work safeguards

Why

#540 correctly removed the global two-live-chat admission gate that could leave eligible chats parked indefinitely. Starting every eligible continuation in one event-loop pass, however, can recreate the startup pressure that the gate was intended to prevent.

This follow-up paces launches rather than limiting live chats. Each pass starts two planned-restart continuations, then follows up after two seconds when it both made progress and found more eligible restart work. It never waits for those recovered turns to finish, so long-running chats cannot hold the remainder hostage.

Design

The existing continuation sweep returns one explicit result to the existing runtime supervisor. There are no per-chat workers, new persisted scheduling flags, new settings, compatibility paths, or permanent short poll. Provider-limit recovery remains separately staggered, and every supervisor pass reuses the boot-captured restart authorization.

Testing

• restart/recovery-focused backend suites: 100 passed
• hermetic fast backend gate: 69 passed
• complete backend suite: 3,583 passed, 1 skipped
• Python compilation and diff checks passed
• hosted CI remains authoritative for the protected merge gate