[FEATURE] Suspend and auto-resume at usage-limit reset instead of ending the session

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

When a session reaches the usage limit, the session ends. The reset time is displayed, but the work itself is dropped, so I have to come back later, notice the limit has refreshed, and restart everything by hand.

This is most painful with long-running orchestration. Running a dynamic workflow, I had roughly 70 of 90 tasks complete when the session was interrupted. On resuming, progress showed 46/90 — about 24 already-finished tasks were discarded and re-run.

So the interruption costs twice: the session stops, and resuming does not restore everything that was already done.

The docs describe resume as replaying "the longest unchanged prefix of agent() calls." In a parallel() or pipeline() fan-out, agents complete out of order, so a contiguous-prefix cache would discard every completed call that sits after the first still-running one. The 70 → 46 drop is consistent with that.

The frustrating part is that long unattended jobs are exactly the workload where a limit window is most likely to be crossed, and exactly where losing the run hurts most.

Proposed Solution

Instead of ending the session at the limit, put it into a suspended state that resumes itself:

1. Show Session resuming in 2:00:00 with a live countdown rather than terminating.
2. Hold the workflow checkpoint / runId while suspended.
3. At 0:00, auto-resume via resumeFromRunId, so nothing already completed is repeated and no manual restart is needed.
4. Apply the same to /loop dynamic mode: schedule the next wake at the reset time instead of ending the loop.

For this to be worth much, resume needs to be lossless. Suggested fix for the 70 → 46 behaviour: key the resume cache per agent() call (on prompt + opts) rather than by contiguous prefix, so out-of-order parallel completions survive.

Most of the machinery already exists and simply isn't wired to the limit event — Workflow already supports resumeFromRunId, and /loop dynamic mode already uses ScheduleWakeup to defer work.

Safety valve: this should be opt-in and bounded (for example "resume once", or a maximum number of windows), so an unattended session cannot spend a fresh limit window on work I would have cancelled had I been watching.

Alternative Solutions

• Manual resume, which is what exists today: note the runId, wait, relaunch. It works but requires me to be present at the moment the limit resets, which defeats the point of a long unattended run.
• Fixing only the lossy resume, without auto-resume. This would help, but I would still have to babysit the clock.
• Pre-emptively splitting work into smaller batches sized to fit inside one limit window. This requires guessing the budget in advance and fragments workflows that are naturally one unit.

Priority

High - Significant impact on productivity

Feature Category

Interactive mode (TUI)

Use Case Example

I kick off a dynamic workflow of ~90 tasks (a codebase-wide audit) and leave the machine running while I am away.

Today: it hits the limit partway through, the session ends, and when I come back I restart it and lose a chunk of completed work in the process.

With this feature: the session shows a countdown, resumes on its own when the window refreshes, and by the time I return the run has finished, with every completed task preserved.

Additional Context

The countdown matters as much as the auto-resume. Seeing resuming in 1:47:22 makes it obvious the work is parked rather than lost, which is not clear today when the session simply ends.