feat(server): threads resume on their own after a usage limit resets

[lukemaj]

Closes #61.

When a provider's usage limit stopped a thread, nothing brought it back: the user had to return after the reset and type "continue". Three threads stopped this way on 2026-09-28 alone (each turn ended as error about 1 s after starting).

When a thread the user started fails while its provider instance has an exhausted usage window with a known reset (the Usage panel's data), the threads toolkit sends one "Continue. (Sent automatically after the usage limit reset.)" a minute after the latest reset. The decision reads the provider's usage windows only, so it covers every provider that reports them, with no error-text parsing.

• Starting another turn or archiving the thread before then cancels it.
• Child threads (sub.*) are skipped: Model Router reroutes or blocks Prism jobs itself, and the planner decides what to do with a blocked job once it resumes.
• Pending resumes live in memory; a server restart drops them.
• It hangs off the threads toolkit's existing domain-event watcher, so no upstream file changes. Upstream Orchestrator V2 has its own "Resume at reset" (feat(v2): resume limited threads when usage resets pingdotgg/t3code#12686), so this goes away with the V2 port.

The Elon record (cuts and evidence) is on #61.

Proof

• vp test run src/mcp/toolkits/threads/usageLimitResume.test.ts: 5 passed on TestClock (resumes once a minute after the reset and not at the reset itself; nothing when not limited; stands down after a newer turn or archive; reset selection across windows).
• vp test run src/mcp/toolkits/threads/: 36 passed, including the real-engine child report-back test that builds this layer.
• apps/server typecheck clean; lint clean on changed files; scripts/fork-check.sh OK.
• Not yet observed on a real limit hit.

Done by Claude Opus 5.5 in Claude Code.

🤖 Generated with Claude Code

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

ℹ️ The exact PR base did not have a successful artifact. Baseline uses the latest successful main measurement shown below.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	13.5 KiB	13.5 KiB	+21 B (+0.2%)	15.1 KiB	✅
Codex	Thread snapshot wire	7.1 KiB	7.1 KiB	+1 B (+0.0%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	6.4 KiB	6.5 KiB	+20 B (+0.3%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	56.2 KiB	56.3 KiB	+44 B (+0.1%)	66.4 KiB	✅
Codex	Live turn messages	9	10	+1 (+11.1%)	21	✅
Claude	Total thread wire	13.5 KiB	13.5 KiB	−13 B (−0.1%)	15.1 KiB	✅
Claude	Thread snapshot wire	7.1 KiB	7.1 KiB	+1 B (+0.0%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	6.4 KiB	6.4 KiB	−14 B (−0.2%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	57.0 KiB	57.0 KiB	0 B (0.0%)	66.4 KiB	✅
Claude	Live turn messages	9	9	0 (0.0%)	21	✅

Baseline: 19a04dc · PR result: 25061bd · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 113.9 KiB
• Claude decoded thread snapshot: 114.6 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.