fix(e2e): chromedriver proxy host/origin, docker exec output, host-access skip, devtoolsproxy timeout

[rgarcia]

Several related e2e/server fixes (the shared/upstream-appropriate pieces of the hypeman-e2e work, plus a pre-existing CI flake).

1. ChromeDriver proxy forwards a non-loopback Host/Origin (HTTP 500)

ChromeDriver (Chrome 111+) rejects requests whose Host/Origin isn't localhost/an IP ("Host header or origin header ... not whitelisted or localhost", HTTP 500). The :9224 proxy did r.Out.Host = r.In.Host, forwarding the inbound host; over a direct 127.0.0.1 hit (docker) that's loopback so it works, but behind an ingress it 500s every request (looks like a slow/never-ready chromedriver). Fix: keep SetURL's loopback host and strip Origin, in both the reverse-proxy path and handleCreateSession. Adds a regression test.

2. Docker exec output includes stream-multiplexing headers

dockerBackend.Exec returned the raw multiplexed Docker stream. Use testcontainers exec.Multiplexed() for clean combined stdout+stderr.

3. Backend.SupportsHostAccess + skip host-access tests on backends without it

Adds Backend.SupportsHostAccess() (docker=true, hypeman=false); TestContainer.Start t.Skips when a test requests HostAccess on a backend that can't bridge to the runner's loopback. Keyed on the request, so a test that doesn't ask for HostAccess is never skipped.

4. devtoolsproxy: raise UpstreamManager detect timeout 20s -> 60s

TestUpstreamManagerDetectsChromiumAndRestart is a pre-existing flake on main: it launches a real browser and waits for the DevTools listening on ws://... line, but chromium cold-start has a long tail on shared CI runners (recent runs: ~6s warm, 15-17s contended, occasionally >20s — failing at exactly ~20.15s, a timeout not a missing line). Raise the wait to 60s. (Supersedes #283, now closed; the browser-binary pinning explored there was unnecessary — the timeout is the real fix.)

🤖 Generated with Claude Code

[firetiger-agent]

Created a monitoring plan for this PR.

What this PR does: Fixes Selenium/WebDriver session creation inside browser VMs when the VM is accessed via an ingress hostname rather than a direct loopback connection — unblocking the hypeman e2e test path and any production customer using the WebDriver protocol behind an ingress.

Intended effect:

• Synthetic browser test pass rate: baseline ~96–120 tests/hr, 0–9 failures/hr; confirmed if this rate holds steady after new VM images are provisioned.
• WaitChromeDriver timeout: baseline — this call hung indefinitely behind an ingress (the bug). Confirmed if e2e tests using the hypeman backend complete without timeout.
• CI regression test TestHandler_RewritesHostAndStripsOrigin: baseline — test did not exist pre-PR. Confirmed if CI passes green on this PR.

Risks:

• Origin strip too broad — Origin header is now removed unconditionally for all proxy paths; if any upstream WebDriver flow legitimately required Origin forwarding, sessions could fail differently. Signal: synthetic test failures > 10/hr for 2+ consecutive hours; alert if sustained.
• WebSocket BiDi path not covered — proxyWebSocket has separate origin handling (OriginPatterns: ["*"]); if BiDi WebSocket sessions were also broken behind an ingress, they remain untested by this fix. Signal: any BiDi connection errors in e2e test output.
• Host header dependency — removal of r.Out.Host = r.In.Host means the upstream Host depends entirely on SetURL; if URL resolution breaks, ChromeDriver could receive a wrong Host. Signal: any WaitChromeDriver timeout or ChromeDriver 500 in test logs.

Status updates will be posted automatically on this PR as monitoring progresses.

View monitor