* feat(browser): direct extension→gateway relay path for remote Chrome (#53599)
Let the OpenClaw Chrome extension pair directly to a remote gateway over
wss:// with no OpenClaw node host on the browser machine — the managed-hosting
path from #53599 (extension is the only thing installed on the laptop).
- Gateway route /browser/extension registered by the browser plugin with
auth:"plugin" + no nodeCapability, so the gateway does not pre-enforce token
auth (browser WebSockets cannot send an Authorization header). The upgrade
handler self-validates the host-local relay secret from ?token=, origin-checks
chrome-extension://, resolves the extension profile, then attaches the socket
to the same ExtensionRelayBridge the loopback relay uses. All CDP synthesis,
tab-group scoping, and the in-process Playwright /cdp client are unchanged.
- `openclaw browser extension pair --gateway-url wss://host` prints a
wss://host/browser/extension#<secret> string; the path ends in /extension so
the extension's existing pairing parser accepts it with zero extension code
changes.
- relay-server: extract attachExtensionWebSocket + export requestToken /
isAllowedExtensionOrigin / EXTENSION_RELAY_MAX_PAYLOAD_BYTES so loopback and
gateway paths share one bind + one frame cap.
- runtime-lifecycle: dispose the shared gateway WebSocketServer on shutdown.
- docs: three remote topologies (same host / direct-to-gateway / via node host).
Coverage: 6 unit tests for the handler's path/503/403/404/401/attach branches.
The full extension→bridge→CDP→Chrome loop over /browser/extension was live-proven
with a real Chrome + the built extension. The real gateway upgrade→handleUpgrade
dispatch for an auth:"plugin" unprotected route is verified against core
(server-http.ts, plugins-http.ts, route-auth.ts).
* fix(browser): harden remote extension pairing
