Electrobun: track upstream CEF fixes (Linux/Windows, multiremote, multi-window, deeplink)

Summary

@wdio/electrobun-service drives the CEF renderer on macOS; CEF stays macOS-only (Linux/Windows CEF can't create the persist:default profile — see #316 and the README Known limitations). Windows ships via the native WebView2 renderer instead (the non-CEF track, #317 — done and gated in 0.1.0), so the service is no longer macOS-only, but the CEF path is. This issue tracks the CEF-side road to 1.0 from our repo: which upstream fix unblocks which CEF surface, why each is required, and the consumer-side re-fold work as each lands.

It is the sibling of #317 (the non-CEF / native-renderer track). The two tracks have independent upstream dependency sets and are both additive — a CEF-app user still needs every fix below even after #317 lands.

Upstream umbrella issue: filed — blackboardsh/electrobun#466 (one umbrella linking electrobun's existing issues, not N duplicates). The CEF-on-Windows finding below is recorded there too.

CEF-on-Windows is a dead end (verified via a spike, 2026-06)

A CEF build on Windows is not a viable alternative to the WebView2 path: it hits the same persist:default profile gap as Linux (Cannot create profile at …\CEF\partitions\default). The first instance limps up and does serve /json (a full functional suite passed against it), but the shared CEF root_cache_path lock doesn't release at teardown on Windows (EPERM), so subsequent app instances fail Failed to initialize CEF. Net: CEF-on-Windows is drivable for a single instance but not re-startable / not multi-instance — it would need fix #1 plus the Windows lock-release angle of fix #3. Windows is already covered by WebView2 (#317), so these CEF fixes are needed only to drive CEF apps on Windows, not for Windows coverage.

Upstream fixes → what each unblocks (CEF)

CEF-on-macOS multi-window/deeplink need fix 1/4; CEF-on-Linux needs 1+2; CEF-on-Windows needs 1 (+3). Windows coverage itself is via WebView2 (#317), not CEF.

Consumer-side re-fold checklist (as each fix lands)

• Re-add the Windows fixture-build + e2e CI jobs — done via the WebView2 path (#317), not CEF
• Lift maxInstances: 1 and validate multiremote — done off-CEF on WebView2 (Windows) and WebKitGTK (Linux, #633); macOS CEF stays single-instance pending fix 3
• Re-add the Linux CEF fixture-build + e2e CI jobs (needs fixes 1+2) — generic Linux e2e already ships via WebKitGTK (#631/#633); this row is the CEF-on-Linux variant only
• Re-fold the macOS CEF window and deeplink suites into the CI matrix (currently local-only via TEST_TYPE=window|deeplink) — needs fixes 1/4
• Relax the launcher's Linux native-mode SevereServiceError guard once Linux is drivable — done for WebKitGTK (drivability #631; parallel workers + multiremote #633); the CEF-on-Linux guard still stands (needs fixes 1+2)
• Drop the fixtures' staggered-second-window workaround + the single-window caveat (CEF) once fix 1 lands
• Drop specFileRetries: 3 in the macOS CEF conf once the race is gone
• Lift the matching README/docs limitation rows; converge on 1.0.0 at full parity

Why a repo-side issue

The upstream umbrella (blackboardsh/electrobun#466) tracks the electrobun changes; this issue tracks both sets of changes from our side — the mapping from upstream fix → CEF service surface, and the re-fold work that is ours regardless of where the fixes land. #317 deliberately scopes these out; this is where they live.

Start with the upstream-fix table in issue #320 and umbrella issue blackboardsh/electrobun#466, then review the unchecked consumer-side checklist. Trace the existing CEF window, deeplink, Linux fixture/e2e, retry, and README limitation work named there. Done means the required upstream fixes are available and the listed CEF suites, CI jobs, documentation, and parity checks are restored.