Preserve messages until the server accepts them

[brsbl]

Human comments

• bb queues messages on the server when the host is offline, but if the server isn't reachable we don't do any client-side queueing
• after a message is sent, if it fails to reach the server, we try to re-insert the message into the composer
• this can lead to a race condition where the message is lost if the user has typed a new message in the composer before the previous one fails

What was wrong

On a spotty connection, a message could disappear if you started typing another draft before the request failed. Send, Queue, and Steer cleared the composer immediately and restored failed messages only if it was still empty. Existing queueing handled an offline execution host, but could not help when the browser could not reach the BB server.

What changed

• Send, Queue, and Steer save ordinary messages locally until server acceptance. You can keep writing in the composer.
• Connection failures show “Connecting to server” and reuse existing retries and queue dispatch.
• Thread-scoped submission keys prevent duplicate acceptance; optional SDK/CLI keys and their guides are included.
• Steering preserves active-turn delivery, plugin holds, and existing Stop/resume behavior.

Built-in commands and older servers use the previous submission behavior. The generated database snapshot accounts for 5,061 added lines.

How you verified

• Remote CI passed on 878c27a24, including checks, tests, and package smoke.
• Chrome for Testing 153.0.8010.36: both composers retained queued messages and newer drafts through network failure; retries reused submission keys.
• Regression-only CI reproduced Stop/resume and overlapping-Steer failures before their fixes.

Live provider delivery was not exercised. 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.

Before / after

Before: c1a64f4b49b0659e92a7aa4434e79d062b3e814f · After: 878c27a24115b939c4e6bbb59b8d79cef353c59a.

Queue requests fail after a newer draft is entered. Captured at 2×: desktop 1440×900 and mobile web 390×844.

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