sandbox: bake WebKit as well as Chromium in the browser image variant

[debuggingfuture]

Context

infra/Dockerfile.sandbox is lean by construction and records that "the chromium / flare-agent variants return when those packages are ported in the parity phase". This issue asks that the browser variant, when it returns, bake both Playwright engines — Chromium and WebKit — not Chromium alone.

vitest-shard makes the ask concrete: a Storybook suite running through Vitest browser mode is exactly the shape that run targets, and a common such suite runs its stories on two engines, because Safari is a large share of consumer traffic and component code carries WebKit-only rendering bugs and per-engine pixel tolerances. With a Chromium-only image, half of that matrix stays on GitHub-hosted runners and the migration buys nothing.

Why the image is the only path

• Browser Rendering cannot serve WebKit. The Playwright fork's docs list Firefox, Android and Electron as unsupported and never mention WebKit, so a requiresBrowser: true CDP slot covers Chromium only. limits.requiresBrowser and "needs the baked browser" stay distinct concerns, and WebKit lives entirely on the second one.
• Runtime install is not a fallback. playwright install --with-deps hangs the Sandbox, and the cloudflare/sandbox base ships only Chromium's shared libraries. WebKit needs its own set (libwoff2, GStreamer, libwebpdemux, libharfbuzz-icu, libenchant, among others), so it has to be baked.
• Size is not the obstacle. Containers cap image size at the instance's disk — 20 GB on the largest type — and mcr.microsoft.com/playwright:v1.58.0-noble, which carries every engine plus system libraries, is a few GB on disk. It is a reasonable reference for what a full tier contains.

What makes the tier usable for a Vitest browser-mode suite

1. The runner and the browsers share a container. Vitest serves the test page from its own Vite server and points the browser at <origin>/__vitest_test__/…. A browser outside the container cannot reach it without tunneling both the Vite HTTP server and the /__vitest_browser_api__ WebSocket, and exposing that off localhost makes Vitest disable api.allowWrite/allowExec. Same-container is the only workable arrangement — another reason a CDP slot doesn't substitute.
2. A pinned, visible Playwright version. A suite asserting per-engine pixel tolerances is sensitive to the browser build, so the tier's Playwright version wants to be pinned and legible to callers rather than floating. This overlaps Pin run container images to immutable tags — and build the pipeline that publishes them #105.
3. vitest-shard should be able to select it, the same way a run selects any other image, so a caller sharding a browser suite doesn't need a bespoke run.

Suggested shape

A WITH_BROWSERS build arg on infra/Dockerfile.sandbox (alongside WITH_BUILD_TOOLS / WITH_RUST) that installs Playwright's Chromium and WebKit with their dependencies at build time, plus a container class bound to it and per-run image selection. Happy to contribute the layer.