After an update restart, resumed threads sit in "Working" for 9 minutes: provider-turn.start waits behind a retrying thread-title.generate effect#25962

Tried to reproduce this on main at e9236274a3, with the Claude Agent provider and "Continue threads after server update" on (the default):

1. A thread running a long foreground Bash turn, with a second message queued. Graceful server stop, then restart. The restart continuation started its run within a second. Resuming the queue from the web client (Send now, which sends queued-run.start) started the queued run at once.
2. The same setup, but the server process was killed with SIGKILL mid-turn and then relaunched. Startup recovery queued one provider-runtime.continue per thread. Both were claimed within about 0.1 s, and their provider-turn.start effects ran within 0.4 s.

In neither case did a start sit idle.

The server runs a thread's effects one at a time, in order. So a queued-run.start that is accepted but never spawns an agent usually means its provider-turn.start effect is waiting behind another effect on the same thread. To tell which one held yours, could you share the following?

• The effect rows for one of the affected threads, from statev2.sqlite in your T3 data folder (userdata). Please send them from a copy, not the live file, and redact paths as needed:
  sql

  1	select rowid, effect_type, status, attempt_count, created_at, available_at, lease_expires_at, completed_at, substr(last_error, 1, 200)
  2	from orchestration_v2_effect_outbox
  3	where thread_id = '<thread id>'
  4	order by rowid desc limit 20;

  If those rows are already gone, send them after it happens again.
• From the server trace, the OrchestrationEffectExecutorV2.execute spans, with their effect type and duration, between the relaunch and the moment the threads started (about 15 minutes later).
• Whether "continue where you left off" was typed by you, or whether it is the "T3 Code restarted and resumed this turn" notice that the server adds after a restart.
• Roughly how large the affected projects' working trees are, including untracked files.

You called it. Effect rows for one of the four threads, UTC, from a copy of statev2.sqlite. The other three match within a second.

provider-turn.start (7062) was accepted at 13:19:47 and completed at 13:28:47. The effect ahead of it was thread-title.generate (7028), created with the thread's first message, on its fifth attempt, made available again at 13:18:07 by the restart recovery, and completed at 13:28:43. The same row exists for all four affected threads plus a fifth idle thread. All five completed between 13:28:43.729 and 13:28:43.852, within 120 ms of each other, and the four provider-turn.start rows completed 1.5 to 4 seconds later. Five independent title calls finishing together looks like a shared timeout or a worker pool freeing at once, possibly the mechanism in #16636.

The server trace for 13:19 to 13:28 has rotated out (10 files of 10 MB cover about 20 minutes at this activity level), so I cannot provide the OrchestrationEffectExecutorV2.execute spans. Tell me what to capture and I will try to reproduce.

"continue where you left off" was typed by me, after the third "T3 Code restarted and resumed this turn" notice. The notices themselves are the server's. Working trees are about 155 MB each, with no uncommitted or untracked files at the time.

Correction to my title: the wait was about 9 minutes, not 15.