feat(cdp): BU_CDP_HTTP to attach to a browser on another host

Upstream can only drive a browser on localhost. The pi extension always goes
through the daemon (src/index.ts uses createDaemonTransport), the daemon
resolves Chrome with discoverWsUrl() (src/daemon/bridge.ts), and that probe is
hardcoded to 127.0.0.1 (src/cdp/discovery.ts). BU_CDP_WS is read only by the
in-process client (src/client.ts), which that path never touches, so it has no
effect on the extension - the only workaround is relaying the remote browser
onto localhost first.

BU_CDP_HTTP="host:port" points at the remote CDP HTTP endpoint. It is resolved
inside discoverEndpoint(), so the daemon and the client both honour it.

Deliberately an HTTP endpoint rather than a WebSocket URL: it is re-resolved on
every discovery call, so the browser UUID is re-read after the remote browser
restarts. Chrome re-mints that UUID on every launch, so a pinned WebSocket URL
goes stale as soon as the remote browser is recycled.

Also skips performSetup's local-process precondition when BU_CDP_HTTP is set:
isBrowserRunning() enumerates local processes and can never see a remote
browser. Step 4 still fails loudly if it is unreachable.

No userDataDir is returned for remote endpoints, since the profile registry
lives on the remote host - profile enumeration degrades to the pre-profile
behaviour rather than reading the wrong machine's Local State.

0 files changed, 0 insertions, 0 deletions