[Feature]: Allow pointing the server browser at a remote CDP endpoint via env var (T3CODE_CDP_WS_ENDPOINT) #24153

Summary

ServerBrowserContexts already has a connectOverCDP(endpoint) path used by the Electron desktop mode. This feature request asks for a single env var — T3CODE_CDP_WS_ENDPOINT — that makes that path reachable for headless/server deployments, without requiring a fork.

Motivation

On Linux servers (and self-hosted setups), users may want to:

• Use a remotely managed Chrome/Chromium instance instead of the bundled chrome-headless-shell (e.g. to avoid the sandboxing/AppArmor setup)
• Route browser traffic through a residential proxy or anti-detect browser that speaks CDP
• Reuse an already-running Chrome instance to save RAM
• Run t3code in environments where downloading and executing the chrome-headless-shell binary is not possible (locked-down CI, network-restricted servers, NixOS, etc.)

Proposed change

If T3CODE_CDP_WS_ENDPOINT is set, the server should:

1. Skip the PreviewBrowser download/verify/install step entirely
2. Call chromium.connectOverCDP(process.env.T3CODE_CDP_WS_ENDPOINT) instead of chromium.launch(executable)

Both pieces of logic already exist in the codebase — the download is in PreviewBrowser.ts and the connectOverCDP call is in ServerBrowserContexts.ts. This would just wire them together behind an env var guard.

Notes

• The remote endpoint must support Page.startScreencast for the viewer streaming to work — standard headless Chrome (--remote-debugging-port) does support this
• This does not affect the Electron desktop browser path at all
• A fallback to the bundled chrome-headless-shell when the env var is unset preserves all existing behaviour

Alternatives considered

Maintaining a local patch on top of the upstream repo — works but requires manual rebase on every update to ServerBrowserContexts.ts or PreviewBrowser.ts.