fix(web): dispatch queued follow-ups after leaving the thread

[macodev00]

What Changed

Queued follow-ups now start while you are in another thread. The working-time counter should show time already spent when you come back.

• A coordinator mounted for the whole app sends queued follow-ups once a tool finishes or the turn ends.
• The open thread, including a draft route that has already promoted to a server thread, still uses the chat send path, so Stop restores the message to the composer.
• The checkout branch selected when the message was queued is stored with it and applied when the follow-up is dispatched.
• Stopping a claimed background send writes that prompt back into the composer draft. It is not returned to the queue as a held row, so the draft is not lost while a metadata or runtime update is still pending.

Fixes pingdotgg#13319

Why

With follow-up behavior set to Queue, a message sent during a running turn lived only inside the open chat view. Leaving the thread deferred thread.turn.start until that thread was selected again, so the counter looked like it started near zero after a long wait.

Stop drains the queue into the composer, but a send that has already claimed the message is no longer in that drain. Cancellation now restores the claimed message to the composer instead of calling holdAtFront.

UI Changes

None (behavior-only). Queued messages dispatch in the background; returning to the thread shows elapsed working time. Stop puts the in-flight prompt back in the composer.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes

  

[macodev00]

Superseded: upstream pingdotgg#13393 opened and closed after Macroscope Not approved (cap HIT).