Keep messages in the queue drawer until server acceptance

[brsbl]

Human comments

What was wrong

Queueing cleared the prompt before server acceptance. A failed request could lose the message if another draft occupied the composer. Retrying an accepted request with a lost response could duplicate it.

What changed

• Send, Queue, and Steer stay in the queue drawer until accepted, leaving the composer free for another draft.
• Delivery reuses TanStack retries, reconnect signals, and the server queue; thread-scoped submission keys prevent duplicate acceptance.
• Fresh Send resumes after Stop; overlapping Steers join the active turn while respecting plugin holds.
• SDK and CLI expose optional submission keys; older servers retain the fallback. CLI guidance is updated.

The generated database snapshot accounts for 5,061 added lines. Browser retention uses localStorage; this adds no separate retry scheduler.

How you verified

• Current head 717110368: targeted Chrome check passed with actual network-request failures in both composers; three retries reused each submission key. Copy now reads “Connecting to server” with a leading spinner.

• Current remote CI: app tests, server tests, checks, and package smoke passed; rerunning the failed packages job after an unrelated desktop server-moved watcher timing assertion.

• Regression-only remote CI reproduced both dispatch bugs before the fix.

• Remote CI passed on b926457f3, including Stop/resume, plugin holds, overlapping Steers, and same-key replay.

• Chrome for Testing 153.0.8010.36 passed main/embedded failure, reload, and newer-draft checks on 43538a60a at desktop/mobile widths.

The browser check also confirmed retry key reuse and disabled unconfirmed Send now buttons. Live provider delivery was not exercised. Matched before/after evidence below was captured from the merge base and exact final head. User QA approval remains pending.

Non-blocking review follow-ups

• Empty-draft keyboard shortcuts can bypass the unconfirmed-row Send now button restriction.
• Updating one pending message reparses the full local backlog.

These P2 findings are outside this PR's review-fix scope.

Before / after

Before: c1a64f4b49b0659e92a7aa4434e79d062b3e814f · After: 7171103689eeef0095ac5d4a2d9af9eac80cdb7e.

Chrome for Testing 153.0.8010.36; desktop 1440×900 and mobile web 390×844, captured at 2×. Same active-thread fixture and inputs on both revisions. Queue requests fail with net::ERR_INTERNET_DISCONNECTED after the next draft is entered. The base loses the submitted message; the head keeps it with a spinner and “Connecting to server.” Both composers retried three times using the same submission ID, with the newer draft preserved.

Connection failures remain pending and retry. A definitive server rejection is a separate error state. “Disconnected” refers to the browser’s live connection to the BB server, not the execution host. These captures replace the earlier HTTP 400 rejection examples.

Connection lost after Queue	Before: message disappears	After: retained while reconnecting
Desktop · both composers
Mobile · main
Mobile · side chat

BB-Thread-ID: thr_fheqd58b9x

AGENT GENERATED