Message sent while a turn is running stays pending forever after the turn ends

Summary

When a user message is sent to a thread while that thread's turn is still running, the request is stored as pending and is never started once the running turn completes. The thread then looks idle; the provider session is reaped after the inactivity threshold (~30 min). Re-sending the same message starts a turn normally.

Environment

• T3 Code desktop AppImage (0.0.37 line), Linux (Ubuntu, Wayland), server on 127.0.0.1:3773
• Providers affected: codex (gpt-5.6-sol) threads; seen on three threads the same day

Evidence (read-only sqlite on userdata/state.sqlite)

projection_turns for one thread, newest first:
  ('pending',   requested 08:46:18, started NULL,     completed NULL)
  ('completed', requested 08:07:49, started 08:07:49, completed 08:57:55)
provider_session_runtime.status = 'stopped' (last_seen 09:16:38)

The pending row never gains started_at after the 08:57:55 completion; no error activity is recorded. The same pattern reproduced on 2026-09-02 after a backend restart (pending requests are not replayed).

Expected

The queued message starts a new turn as soon as the running turn completes, or the UI refuses/queues visibly.

Workaround

Send only after the turn has ended; re-send any message that shows as pending with no started turn.

Start with the turn lifecycle represented by projection_turns in userdata/state.sqlite, and compare it with provider_session_runtime after a turn completes. Reproduce by sending a message during an active turn, then verify the pending row starts automatically after completion and is replayed after a backend restart without resending.