Let Send queue messages while the thread is busy or the connection is reconnecting

[matthias-scale]

Problem

When a thread is starting up, a send is still going out, or the client is reconnecting to its environment, Send is blocked and the user has to wait before typing the next message. That happens often on remote and tunnel connections, and on slow provider startup.

Proposal

Send always accepts the message. If the server can take it, it goes into the existing server-side queue as today. If it can't, the client holds it in a small local outbox (IndexedDB, so attachments survive a reload). The outbox shows in the existing Queued panel with the same pause, edit and cancel controls, and drains into the normal send path once the connection and thread are ready.

Real blocks stay as they are: no model selected, invalid attachments, provider not set up.

Retries reuse the same command ID (derived from the message ID), so the server's command receipts dedupe a send that landed before the client saw the reply.

Prototype

Working branch: matthias-scale/t3code fix/queue-send-while-unresponsive (web and desktop; mobile not yet). Checked by hand against a copy of real data: stopped the server, sent a message (shown as Queued with a reconnecting banner), cancel removed it, a second message was delivered exactly once after the server came back.

Happy to cut scope (for example, drop persistence across reloads) if you'd prefer a smaller first step. Is this direction OK?