[Bug]: A message sent while a thread is usage-limited starts and fails instead of waiting for the reset #27047

This is the remaining part of #19327, filed on its own as asked there.

Area

apps/server

Steps to reproduce

1. Run a thread until its provider returns a usage limit with a known reset time. The run fails with class usage_limit, and the thread offers Resume at reset.
2. Before the reset, type a new message and press Send.

Expected behavior

The message waits in the thread's queue and runs at the reset, the same way queued messages already wait while a limit blocks the thread (startNextQueuedRun checks usageLimitBlockedRun).

Actual behavior

The thread is idle, so the send starts a run at once. The run fails on the same limit, and the armed resume is cancelled. After the reset the message has to be sent again.

On main 960d576, message.dispatch in apps/server/src/orchestration-v2/Orchestrator.ts queues a send only behind an active run or a run whose worktree is missing (queueBehindRun = activeRun ?? worktreeMissingRun, line 5511). A usage-limited run is neither. Open PR #24030 adds this hold for background wakes only. User sends still start immediately.

Proposed behavior

When the thread's latest root run failed on a usage limit and the reset is in the future, a user send queues behind that run and arms the thread's limit recovery with auto-resume. With no known reset, sends start immediately as today. A fix is ready: a few lines in message.dispatch plus a runtimeLayer.test.ts case that fails on main. I will open it as a PR once this is triaged.

Impact

Minor bug or occasional failure

Version or commit

main @ 960d576

Environment

Windows desktop host