Send now on a shared first message can take another connection's delivery as its own #2162

Follow-up from #1591 (the one item its fix PR leaves).

Problem

actOnPending in src/lib/useComposerSends.ts counts an explicit Send now of a bridge-owned row as delivered when a pending-messages frame for the pane lists the row's id as removed with outcome: "sent" before the action's result arrives. The frame does not say which connection sent it.

A pane's first message is kept under FIRST_MESSAGE_OWNER on the bridge (server/core/pending.ts, pending-action): every attached connection may send it now or discard it. When two browsers press Send now on the same first message, the one that loses the race can still get { ok: true } (from replayPendingOutcome) and the other connection's sent removal. It then treats the send as its own and opens the terminal peek for a command it did not send.

Effect: only the view. The message is sent once, and no text is lost or typed twice.

Direction

A client-only fix cannot tell the two cases apart. The pending-result answer would need to say that this action dispatched the message (the server already knows: dispatched in the pending-action handler), for example delivered: true. The client would then open the peek only on that field, or on the current frame check against an older bridge. That is a WS contract change: a server change the remote bundle carries, so REMOTE_BUNDLE_VERSION applies, and it needs a real review.