[Bug]: Usage-limit auto-resume never retries when the resumed run fails again after the reset #29042

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. Run a thread until the provider returns a usage limit. The run fails with failure.class = "usage_limit" and a resetAt time T, and auto-resume is armed.
2. Let the clock pass T.
3. The sweep in UsageLimitRecoveryWorker dispatches Continue where you left off. as soon as the stored resetAt is <= now (getLimitRecoveryCandidates in apps/server/src/orchestration-v2/ProjectionStore.ts, limitRecoveryCommand in UsageLimitRecoveryWorker.ts). There is no margin after T.
4. If the provider still rejects requests at T (its reset is a little later than the reported resetAt, or the server and provider clocks disagree), the resumed run fails again with usage_limit.

I have not reproduced step 4 on demand. It is inferred from code reading and from a report of a resume that failed right after the reset.

Expected behavior

Auto-resume continues the thread only once the provider is actually accepting requests again, and it does not fail on the first attempt because of a few seconds or minutes of skew.

Actual behavior

The continuation is dispatched at the exact reported reset time. When the provider still refuses requests at that instant, the thread fails again instead of resuming.

Impact

Major degradation or frequent failure

Version or commit

0.1.1-nightly.20261016.3190 (installed build). Checked against main @ 7a760a9a88.

Environment

Linux (Arch, kernel 7.2.11), T3 Code desktop AppImage, Claude/Codex usage-limited threads.

Workaround

Continue the thread by hand after the reset.

Related

Different symptom, same code path: #17808 (never fires), #26037 (resumes but leaves queue paused).