fix(producer): graded video renders split into chunks that finish inside the worker limit - #5883

Review at cf4e772a.

Strengths

• plan.ts:427-429: frames are priced at max(per-pixel estimate, measured), so the measured cost can only add chunks. It never lowers the price below the existing estimate, and an ungraded plan is unchanged by construction.
• chunkSizingUsesFrameCost (plan.ts:448) lifts the old pinsChunking condition into one predicate. resolveMaxParallelChunks and the measure-or-not decision both use it, so they can't disagree.
• The measuring session mirrors a chunk worker. It uses the same buildChunkCaptureOptions, browserGpuMode: "software" (plan.ts:1086), and the injected video frames. It extracts the deferred frames for exactly the indices selectCaptureCalibrationFrames(totalFrames) returns, which is the function measureCaptureCostFromSession calls too, so no sampled frame is drawn without its video.

Review focus

• Sample size and outliers: 5 frames (0, 25%, 50%, 75%, last). The p95 of 5 is the slowest sample (captureCost.ts:222), so a cold or contended outlier biases the price up. That's the safe direction: more chunks, never a chunk that runs too long. Browser start and shader compile happen in initializeSession, before the timed samples, and the body's 10.54 s next to the ~17 s setup is consistent with that. Static-frame dedup is bypassed during calibration (captureCost.ts:272-273), so a sample can't read near 0 ms.
• Chunk bounds: no zero-frame or runaway chunks. wide is clamped to ≥1 (:515). If even one frame doesn't fit the margin, maxFramesPerChunk < 1 makes needed Infinity, which raises the typed ChunkExceedsWorkerTimeoutError (:522-529). The 256-chunk ceiling also raises that error rather than producing an oversized chunk, and resolveChunkPlan still asserts positive integers. At 10.5 s/frame with a 900 s limit, a chunk holds 58 frames, so the refusal starts at about 14.8k frames (about 10 min at 24 fps).
• Timeout margin: unchanged at 0.75 (:424), and the measured chunks (160-178 s against a 218 s prediction) sit comfortably inside it. Chunk workers run several capture workers (calculateOptimalWorkers) while the planner measures one session, so the prediction is conservative.
• Non-graded renders: with measureFrameCost false, the third allSettled slot is undefined and the chunk plan is the same resolveChunkPlan(..., maxParallel, ...) as before, just computed later. Also, chunkFrames.ts is a faithful move. I diffed the removed renderChunk.ts lines against the new file with comments stripped. The only changes are slice → frames: Iterable<number> (the caller expands the slice) and the capture-options object turned into buildChunkCaptureOptions. That reads encoder.quality, which is what job.config.quality was (buildSyntheticRenderJob({ quality: encoder.quality })).

Important (non-blocking)

1. When measurement fails (plan.ts:1431), a rejected measurement now fails the whole plan. That covers Chrome launch, ffmpeg extraction of the sampled frames, or a capture timeout under the shortened calibration protocolTimeout. The measurement is sizing advice, and the per-pixel price is still available. Falling back to it, or to a conservative floor, with a log.warn would keep a transient plan-side flake from failing a render the chunks might have finished. Failing fast is defensible, since an under-sized graded plan times out anyway, so I'm not blocking. If it stays, a sentence in the code saying it's deliberate would help.

Nits
2. planNeedsFrameCostMeasurement (:444) is a static regex on the compiled HTML. Grading added at runtime by script isn't seen, and that render keeps the old per-pixel plan. The attribute appearing in text or comments only costs an unnecessary measurement. Both are fine for now.
3. The measurement runs alongside the audio mix and prepublish on the same box. On a small plan instance that contention inflates the p95. That's the safe direction, but it's worth knowing when reading a surprisingly high [plan] measured frame cost.

CI at cf4e772a: all 8 required checks passed. The first CI run on this head (run 39264487869, 13:56Z) ran Build, Test, Test: runtime contract and Typecheck, plus Producer unit and integration tests, and all succeeded. Windows render verification run 39264487857 passed Render on windows-latest and Tests on windows-latest. A later re-trigger at 14:18Z on the same SHA saw no changed paths and skipped them. regression and Semantic PR title are green.

Verdict: APPROVE
Reasoning: The measured price can only make chunks smaller, chunk-count bounds and the timeout refusal are intact, non-graded plans are unchanged, and the extracted module is a faithful move. Required CI ran and passed at this exact head.

— Via