fix(browser): honor OPENCLI_CDP_ENDPOINT for website CLIs (remote-Chrome mode)

[luckydududu]

Problem

docs/advanced/remote-chrome.md promises that setting OPENCLI_CDP_ENDPOINT lets OpenCLI drive a remote Chrome (headless servers, CI — the doc even ships a CI recipe with xvfb + --remote-debugging-port). In practice the variable is only honored for Electron app CLIs: website CLIs always route through the Browser Bridge extension (getBrowserFactory → BrowserBridge), which cannot be installed in many remote/headless setups. So opencli twitter timeline etc. fail with Browser Bridge extension not connected even when a perfectly good remote Chrome is reachable.

Fix

• runtime: getBrowserFactory returns CDPBridge for any site when OPENCLI_CDP_ENDPOINT is set (explicit opt-in; default behavior unchanged, Electron unchanged).
• execution: pass the manual endpoint for non-Electron sites. No localhost port probe here — the endpoint may live on another machine; CDPBridge already validates it when fetching /json.
• cdp: website sessions open a dedicated tab via /json/new (PUT, with GET fallback for pre-111 Chrome) instead of attaching to whichever existing tab ranks first — a shared remote browser may have the user's real tabs open, and hijacking one to navigate to the site would be destructive. The tab is closed on close() (best-effort). ws:// endpoints and the existing attach path (Electron / no dedicatedTarget) keep their previous behavior, including OPENCLI_CDP_TARGET ranking.

Tests

• Dedicated-tab lifecycle against a real local HTTP server: create → close sequence, PUT→GET fallback on 405, and legacy attach path unchanged (GET /json only).
• Factory routing unit tests (env unset → BrowserBridge; set → CDPBridge).
• npx tsc --noEmit clean; full npm test — the only failures are 2 pre-existing ones in src/download/index.test.ts (cross-domain redirect cookies), reproducible on a clean main checkout in the same environment.

Verified end-to-end

Against a real Chrome on another machine over the network (no extension installed in that Chrome):

$ export OPENCLI_CDP_ENDPOINT="http://<remote-host>"
$ opencli twitter whoami
logged_in: true
username: <redacted>
$ opencli twitter timeline --type for-you --limit 5 --format json
# 5 tweets, correct content

Tab hygiene confirmed: repeated runs leave no extra tabs in the shared browser.

Docs

remote-chrome.md updated to state that website CLIs work in this mode, describe the dedicated-tab semantics, and clarify ws:// endpoint behavior.