fix(webview2/win): pass --remote-debugging-port via the WebView2 API (survives Runtime 150 elevation hardening)

Draft: the elevated-host case isn't locally reproducible — see Testing.

Problem

WebView2 Runtime 150 made elevated host processes ignore WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS; only args passed through the WebView2 API survive (WebView2Feedback#5640).

That env var was the only route the debug port had into the WebView2 renderer, so CDP/WebDriver automation breaks silently — the DevTools endpoint never opens and session creation times out. It hits elevated CI hosts such as GitHub-hosted Windows runners, once their WebView2 auto-updated 149 → 150.

Fix

createWebView2View now passes --remote-debugging-port=<port> through put_AdditionalBrowserArguments, which is honored when elevated. The port comes from the same sources as CEF — build.json chromiumFlags, ELECTROBUN_CEF_REMOTE_DEBUGGING_PORT, or the dev-build default — reusing resolveRemoteDebugging() / selectRemoteDebuggingPort() unchanged.

Two details worth flagging for review:

• Resolved once per process (webView2RemoteDebuggingPort()), not per view. WebView2 rejects a second environment on the same user data folder when AdditionalBrowserArguments differ (ERROR_INVALID_STATE, 0x8007139F), and dev builds pick the port by scanning for a free one — so resolving per view would scan past the port view 1 already bound and stop view 2 being created.
• g_remoteDebugPort is left to CEF, which reads it in OpenRemoteDevToolsFrontend. A WebView2 port must not overwrite it in an app using both renderers.

Scope is limited to the remote-debugging port, matching CEF; general chromiumFlags passthrough would be a separate change.

Testing

Windows 11 x64, MSVC 19.44, WebView2 Runtime 152.0.4191.66 — past the 150 change.

• Compiles with the flags build.ts uses for Windows, against the vendored WebView2, CEF and Dawn headers. Warning output identical to main.
• Port arrives — CDP /json/version returns Edg/152.0.4191.66 with a webSocketDebuggerUrl.
• Multi-view — resolving per view fails view 2 with 0x8007139f; resolving once creates both, CDP up.
• chromium_flags.test.cpp compiles and passes.

Not covered: the elevated path itself. The harness runs unelevated, where the env var still works, so that behaviour rests on WebView2Feedback#5640. The multi-view result comes from a harness reproducing the resolution logic against the real runtime, not an end-to-end Electrobun app.

Reported downstream against WebdriverIO's Electrobun testing service, where it breaks the Windows WebView2 E2E lanes.

🤖 Generated with Claude Code