A remote PC still lists a pane's new agent up to 5 s late #555

What happens

On a remote PC, a pane whose agent has just started can still be listed as a shell for up to 5 seconds. #537 fixed this for the PC the connection server runs on; a remote PC's bridge was left as it was.

A device that opens such a pane in that time takes it for a shell: with chat as the lens it still opens the terminal (a shell has no chat), attaches without keep_size, and resizes the terminal shared with other devices. When the roster catches up, the page switches to chat with the grid already fitted to it.

Why

The connection server reads a remote PC's snapshot every 5 s and again on each pane-status, pane-exited or session-changed frame the bridge sends (server/machines.ts, observe). A pane-status frame names no agent, and an agent that herdr names without a status change the bridge's collector is subscribed to (a pane created a moment ago, an agent that starts in an idle shell) sends no frame at all. So nothing asks for the snapshot until the next 5 s read.

On the local PC, #537 added MachineManager.localAgents(): the status collector hands on each pane's agent (from an event, and from the snapshot it reconciles from, after its replays), and the roster is read again when that is news. A bridge runs with machines: false, so that call does nothing there.

A fix

The bridge has the same collector. When it hears an agent anew it could send a frame that makes the connection server read the snapshot again; session-changed already does, and needs no change to the wire. That keeps older connection servers working. Carrying agent on pane-status instead would be a protocol change (shared/protocol.ts, a contract test, the demo transport) and a new remote bundle.

Either way the remote bundle version has to go up, since the bridge's behaviour changes.

Not measured

How late a remote roster is in practice. The 4.8 s measured for #537 was on the local roster; the remote path adds the bridge's own reconcile debounce and the round trip.