Bug description

On HyperFrames 0.8.74, hyperframes check . --at ... --browser-gpu --json hangs for several minutes and then records check_runtime_failure: Protocol error (Runtime.callFunctionOn): Target closed. The same composition renders all 3261 frames successfully at delivery quality with hardware GPU.

Reproduction

1. Use a 1080x1920, 30 fps, 108.7 second HTML composition containing one video, one audio track, GSAP timeline elements, and local PNG assets.
2. Run HF_CHECK_MAX_WAIT_MS=90000 hyperframes check . --at 31.90 --browser-gpu --json.
3. The command stalls beyond the requested max wait and is later killed by the shell timeout. A larger multi-timestamp run wrote the attached failure shape below.
4. Run hyperframes render . --quality delivery --workers 4 --browser-gpu.
5. Rendering completes successfully: 3261/3261 frames, artifact validated.

Actual result

{
  "ok": false,
  "runtime": {
    "ok": false,
    "findings": [{
      "code": "check_runtime_failure",
      "message": "Protocol error (Runtime.callFunctionOn): Target closed"
    }]
  },
  "layout": {"ok": true},
  "motion": {"ok": true}
}

The command also warns that two PNG assets (2.2 MB and 5.8 MB) exceed the 2 MB inline limit. That warning may be relevant, but browser rendering still resolves those same local assets correctly.

Expected result

check --at should either complete successfully for the requested timestamps, or fail promptly with a bounded actionable error. HF_CHECK_MAX_WAIT_MS should prevent an unbounded hang.

Environment

• HyperFrames: 0.8.74 (project-pinned)
• Node: v22.23.1
• macOS 27.0, Apple M3 Ultra
• Browser GPU: ANGLE Metal hardware
• Render path succeeds with --quality delivery --workers 4 --browser-gpu
• Lint: 0 errors; warnings only