fix(engine): add --autoplay-policy=no-user-gesture-required to headless Chrome args (#1177)

GSAP's volume tween on an <audio> element causes Chrome to construct an
AudioContext. In headless Chrome, the autoplay policy blocks AudioContext
startup with "The AudioContext was not allowed to start" — the frame-capture
loop then waits for it indefinitely and deadlocks before the BeginFrame
fallback can recover. The render hangs at "Starting frame capture" with
0 output frames and times out.

Adding --autoplay-policy=no-user-gesture-required lets the AudioContext start
without a user gesture, which is safe in the headless rendering context where
no real user interaction is possible anyway.

Applied to both the main Chrome launch (browserManager) and the HDR capture
path (hdrCapture).

Fixes #1176. Reported by Abhai (Infinity agent, external).

Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>

packages/engine/src/services/browserManager.ts

@@ -580,6 +580,12 @@ export function buildChromeArgs(
     ...getLowMemoryFlags(),
     // Disable features that add overhead
     "--disable-features=AudioServiceOutOfProcess,IsolateOrigins,site-per-process,Translate,BackForwardCache,IntensiveWakeUpThrottling",
+    // Allow AudioContext to start without a user gesture in headless Chrome.
+    // Without this flag, any code path that constructs an AudioContext
+    // (including GSAP tweening an <audio> element's volume) triggers the
+    // autoplay policy and causes the AudioContext to stay suspended. The
+    // frame-capture loop then blocks waiting for it, deadlocking the render.
+    "--autoplay-policy=no-user-gesture-required",
   ];
 
   if (browserGpuMode !== "software") {

packages/engine/src/services/hdrCapture.ts

@@ -310,5 +310,6 @@ export function buildHdrChromeArgs(width: number, height: number): string[] {
     "--disable-sync",
     "--no-zygote",
     "--force-gpu-mem-available-mb=4096",
+    "--autoplay-policy=no-user-gesture-required",
   ];
 }