fix(engine): drawElement falls back on gpu-less linux and beginframe launches instead of hanging self-verify - #7324

What

drawElement fast capture now falls back cleanly in two cases where it used to hang the render for about 300 s:

• A GPU-less Linux host with browserGpuMode: "hardware". detectGpuBackend read a null or throwing WebGL context as a real GPU, so drawElement engaged on a BeginFrame launch. It now falls back with deGateReason: "webgl_unavailable". Software renderers other than SwiftShader (llvmpipe, lavapipe, softpipe, Mesa offscreen, Microsoft Basic Render Driver) count as software, using the token list browserManager.ts already had.
• Any BeginFrame launch. drawElement's self-verify reads its ground truth on a page with no BeginFrame driver, and that never finishes under --enable-begin-frame-control. Since Linux headless-shell launches BeginFrame, this hit Linux hosts with a GPU too. drawElement now doesn't engage there, with deGateReason: "beginframe_no_self_verify", rather than running without its self-verify.

Why

drawElement on software GL gives no speedup, so the engine is meant to fall back there (team notes, "SwiftShader drawElement speedup" in the graveyard). And config.ts treats self-verify as the safety net drawElement must not ship without, which #7255 extended to segmented and sequential capture. Both paths hung and failed before, so gating them loses nothing that worked.

Related work

• Refs feat(producer): a capture segment extracts the frames it shows and deletes them #7241, feat(producer): render long videos with windowed source frames behind a flag #7242, the windowed source frames. The second commit adds the drawElement case for the on-demand self-verify hook that was asked for in review there.
• Builds on fix(producer): segmented and sequential capture check drawElement samples #7255, the drawElement sample checks.

How

• drawElementService.ts: detectGpuBackend reports webglAvailable, and the shared SOFTWARE_WEBGL_RENDERER_TOKENS decide what counts as software.
• frameCapture.ts: drawElementGate decides the fallback in order: backend first, then launch mode. HF_FORCE_DRAWELEMENT bypasses only the launch gate.
• The gate reasons are added to the observability unions.

Test plan

• Unit tests: a null or throwing WebGL context reads as unavailable. llvmpipe and Microsoft Basic Render Driver read as software. A real GPU and real SwiftShader are unchanged. A BeginFrame launch with a GPU backend gates. A screenshot launch still engages. Fails without the fix: the new drawElementService tests failed on the missing webglAvailable result, and the gate tests failed before drawElementGate existed.
• On a GPU-less Linux devbox (Chrome headless-shell 153.0.8010.36, CI's build), a hardware render took 305 s before, stalling at self-verify. After: 1.9 s, webgl_unavailable, completed. With the GPU reading faked: 1.9 s, beginframe_no_self_verify.
• windowedFrames.integration.test.ts: the drawElement case runs drawElement on macOS (8 samples armed, 1 recycle, on-demand folders seen, none left). On Linux it asserts the gated fallback. HF_TEST_REQUIRE_DRAWELEMENT=1 makes a fallback fail, and is meant for macOS and Windows GPU hosts.
• Engine and producer typecheck, comment checks.

Not exercised

• Linux with a real GPU: the BeginFrame gate is inferred from the launch path and the flag, not measured on one.
• Which call stalls: whether it's Page.captureScreenshot itself, or the truth page's goto or pollHfReady, isn't confirmed. The gate sits before all of them.
• Self-verify on macOS has no deadline. Under heavy machine load (load average about 90 from other Chromes), one macOS run hung 600 s at a session's self-verify. A retry at load 34 passed. That's a screenshot launch, which this PR doesn't change, so I'm flagging it as a follow-up.

🤖 Generated with Claude Code