[Bug]: inactivity auto-settle cancels a pending usage-limit auto-resume#18928

Thanks. I checked this against main and it holds up.

• isAutoSettlementCandidate in ThreadSettlementService.ts skips threads with a snooze still in the future, but it never looks at limitRecovery. A thread that's failed on usage_limit and armed to auto-resume with no snooze counts as an ordinary idle thread.
• In resolveAutoSettlementAt, inactivity is measured from the last user or run timestamps. Only a snooze wake (snoozedUntil / lastSnoozeWakeAt) restarts it, so a weekly reset easily falls past the 1–3 day window.
• When thread.settle runs, limitRecoveryCommand in UsageLimitRecoveryWorker.ts returns null for settledOverride === "settled". The recovery candidates leave settled threads out too, so the resume gets dropped without any notice and the banner still offers "Cancel auto-resume".

I'm accepting this as a bug. The fix you suggested fits how #16674 handles snoozes: while the reset is still ahead, treat an armed limitRecovery (same run, reset in the future) as a parked wake in isAutoSettlementCandidate, then add the reset time as an inactivity anchor in resolveAutoSettlementAt. #17808 shows the same symptom but has a different cause (its reset fell inside the window), so it stays separate.

Until this is fixed, any of these avoids it: turn on Snooze limited threads together with auto-resume, pin the thread, or turn off inactivity auto-settle.

Triage on Linux x64, current main 70e5e384da, using the web dev server in a browser (pnpm install, then vp run dev) with isolated worktree state. Auto-resume was on, snooze was off, and inactivity auto-settle remained on at 3 days. A Codex turn completed with TRIAGE_OK; it did not hit a usage limit, so no pending recovery was armed. This is not a reproduction of the reported failure.

The initial real-data snapshot could not migrate because its migration history differs from main; the app started with fresh state. The minimum inactivity window is one day, beyond this 60-minute triage. I did not change database timestamps or count the source trace as a live reproduction.

Has this sequence now occurred in a live run? Please provide the provider and version, the limit-stop time and reset timestamp, the inactivity setting, and a sanitized state/log excerpt showing limitRecovery and settledOverride before and after the sweep. Alternatively, a deterministic runtime fixture that reaches the limit and advances the inactivity window would let us verify it without a multi-day wait. Leaving open pending that evidence.

It hasn't happened to me in a live run: since 2026-10-13 I've had Snooze limited threads on alongside auto-resume, which avoids it, as you noted. But there's deterministic evidence:

• #18937's tests: in ProjectionSettlement.test.ts and ThreadSettlementService.test.ts, the four tests covering this fail on main and pass with the fix. They arm limitRecovery and run the sweep past the inactivity window without waiting.
• On a development server (vp run dev:server, on a copy of my data from vp run migrate-dev-db), running a fork that includes main up to 80664d5, I gave one stopped thread the state a usage limit leaves: limitRecovery armed for its latest run, autoResume true, snooze false, a reset a week away. I also moved its activity back four days, with auto-settle at the default three days. Without the fix, the first sweep settled it seconds after the server started, with limitRecovery still armed. With #18937's change it stayed unsettled through three sweeps, and with the reset moved four days into the past the next sweep settled it, with settledAt at the reset.

That second check edits timestamps, so it isn't the live run you asked for, but together with the tests it shows the path.