Parallel screenshot-mode renders serialize on one shared browser (forceScreenshot never gets separate browsers)

[yahelshiran-rvr]

Describe the bug

On Linux, parallel renders in screenshot mode (forceScreenshot=true ‚all transparent
webm/mov) run every worker through the single shared pooledBrowser, so their
Page.captureScreenshot calls serialize. Capture throughput stays ~1X no matter how
high workers=N is.

Cause: in parallelCoordinator.ts (executeWorkerTask), the needsSeparateBrowsers gate
includes !config?.forceScreenshot, so screenshot mode always shares the pool:

const needsSeparateBrowsers =
parallel && process.platform === "linux" &&
!config?.forceScreenshot && // <-- excludes screenshot mode
!supersampling &&
resolveHeadlessShellPath(config) !== undefined;

The comment justifies this as a guard for BeginFrame's process-global compositor race‚
but that race is BeginFrame-only. Screenshot capture has no such race, so excluding it
gives no safety and just kills parallelism for alpha renders.

Fix: drop the !config?.forceScreenshot clause so screenshot-mode workers also get a
dedicated browser (enableBrowserPool:false). Distinct from #1788 (captureBeyondViewport).

Link to reproduction

Steps to reproduce

2. Run: npx hyperframes render --format webm --workers 4 (Linux/software rendering)
3. Watch process list: only 1 browser launches; captureFrameMs ~ totalFrames X captureAvgMs.
4. Compare against workers=1 ‚near-identical capture time despite 4 workers.

Expected behavior

With workers=4, four capture browsers run concurrently and capture time drops
roughly proportionally ‚ same as non-screenshot (BeginFrame) parallel renders already do.

Actual behavior

Only 1 browser launches; all 4 workers serialize through it. Capture time is flat vs
workers=1. On a 180-frame/227ms-per-frame comp (Linux, SwiftShader, 16 vCPU):

shared pool (current): 1 browser, capture 40.9s, wall 50.2s
separate browsers: 4 browsers, capture 19.2s, wall 28.4s (~2.1X capture)

Output is pixel-identical between the two ‚only capture time differs. Heavy comps
serialize long enough to hit the sync-render timeout.

Environment

✓ Version          0.7.21
✓ Node.js          v22.16.0 (linux amd64)
✓ FFmpeg           ffmpeg version 5.1.9-0+deb12u1
✓ Chrome           Chromium 149.0.7827.53 (bundled: /usr/bin/chromium)

Additional context

No response