fix(daemon): report a connected extension that cannot run commands

[iuyo5678]

Problem

A browser can show as connected in the extension popup, bsk doctor, and bsk browsers while session start and tool calls wait until they time out. Reconnecting replaces the daemon registration but leaves calls on the old socket blocked. A socket that stays open and stops sending frames also stays registered until the existing liveness window, about 60 seconds. A browser process can answer a WebSocket ping before its service worker sends system.handshake; those connections are dropped after 5 seconds.

Change

Replacing a registration now fails that socket's in-flight calls immediately. Session start retries once on the new connection. If that connection is replaced too, the call reports that the extension is reconnecting and does not retry again. Tool calls are not retried. Clicks, key presses, wheel input, uploads, and downloads keep an unknown outcome, so a caller does not repeat a side effect that may already have reached the page. A disconnect that does not install a newer generation is unchanged.

A timed-out call marks the browser unresponsive only when no inbound frame has arrived for one heartbeat interval, 20 seconds. The registry entry and its other sessions stay. Later commands fail immediately with the same reason until any inbound frame clears the mark. Removal is still the existing liveness reaper. A shorter timeout does not mark the browser when a frame arrived inside that interval.

After upgrade the daemon sends one ping. A pong without a handshake extends the first-frame wait once, by 10 seconds. If neither a pong nor a handshake arrives, the connection still drops at 5 seconds. Ping and pong are not accepted as the handshake.

bsk doctor reports a warning and still exits successfully. bsk browsers names each unresponsive browser. The popup is unchanged, because a frozen service worker cannot repaint it. There is no new error code. Existing codes carry extension_reconnected, extension_reconnecting, or extension_unresponsive. BrowserStatusEntry.unresponsive defaults to false, so older status payloads still decode.

Related: #294

Validation

• cargo test -p bsk-protocol: 156 passed.
• cargo test -p bsk --lib: passed, including replacement, the single session-start retry, the 20-second silence threshold, handshake grace, and the CLI reason text.
• Every crates/bsk-cli integration test target passed. One auto_spawn case timed out under parallel load and passed when run alone.
• cargo fmt --all -- --check and cargo clippy --workspace --all-targets --locked -- -D warnings passed.
• Not run against a live Chrome service worker. The handshake grace and the decision to leave the popup unchanged are covered by the daemon tests and the constraints above.