Feature request: attach to an existing CDP endpoint instead of launching Chrome

[zengbo]

Summary

Support an attach mode where the daemon connects to an already-running Chrome's CDP endpoint (e.g. HERDR_BROWSER_CDP_URL=http://host:port) instead of spawning a local browser process.

Motivation

I run full Chromium as a service inside a local k3s cluster (ClusterIP, CDP on 9222) and want Herdr browser panes to drive it. More generally, attach mode covers any browser the daemon cannot or should not own: a container, a remote host, or a shared long-lived instance whose login state should survive pane close.

Current workaround (works, but is a hack)

launchChrome() has no attach path, so I point HERDR_BROWSER_CHROME at a shell script that impersonates the Chrome binary: it parses the daemon-chosen --remote-debugging-port=N and runs socat to forward 127.0.0.1:N to the remote endpoint. The daemon's ready-poll (/json/version), navigation, and screenshot capture all work through the forward.

Two teardown pitfalls in case anyone tries the same (each produced a ~90s hang after the work completed):

1. The forwarder inherits the stderr pipe the daemon uses to capture Chrome's stderr; the spawning runtime won't exit while any forked forwarder process holds the write end. The forwarder's stderr must be redirected away.
2. socat in fork mode spawns one child per connection; SIGTERM to the listener alone orphans the child carrying the live CDP websocket, so the daemon side never sees the socket close. Children must be killed before the listener.

Sketch

• If a CDP URL is configured, skip launchChrome(): poll <url>/json/version for readiness and connect the gateway to the reported webSocketDebuggerUrl.
• Lifecycle: close() disconnects instead of SIGTERM/SIGKILL; the remote browser (and its profile flags) is owned by whoever started it. This also gives a nice property my workaround already exhibits: browser state survives pane close.
• Chrome's DevTools HTTP endpoint rejects non-IP Host headers, so documenting "use an IP or localhost forward" (or setting an explicit Host) may be needed for DNS-named endpoints.

Happy to test a branch, or send a PR if you'd take one — maintainer preference on config surface (env var vs plugin config) welcome.