fix: honor FFMPEG_PROCESS_TIMEOUT_MS during video-frame extraction

[miga-heygen]

Summary

FFMPEG_PROCESS_TIMEOUT_MS resolves correctly into EngineConfig.ffmpegProcessTimeout and is correctly forwarded to the audio-extraction ffmpeg call, but runExtractVideosStage — shared by both the in-process renderer and distributed plan() — built the config object it passes to extractAllVideoFrames with only { extractCacheDir, extractCacheMaxBytes }, silently dropping ffmpegProcessTimeout even though the full EngineConfig (which already has that field) was in scope. That config flows straight into extractVideoFramesRange, which falls back to a hardcoded 300s deadline whenever the field is undefined — so video-frame extraction always used a fixed 300s timeout no matter what the env var was set to, independent of --workers, cache settings, or keyframe density.

Fix

One-line addition: ffmpegProcessTimeout: cfg.ffmpegProcessTimeout in the config literal passed to extractAllVideoFrames, alongside the two cache fields already there.

Worth noting: this does unify video-frame extraction onto the same timeout knob that other ffmpeg operations (mux/faststart, audio extraction) already use. If a deployment set FFMPEG_PROCESS_TIMEOUT_MS low for a different ffmpeg step, video extraction on long/large source clips now inherits that same shorter deadline instead of the previous fixed 300s ceiling — this is the intended effect of the fix (the whole point is making the var actually apply here), but worth being aware of if a very short value is already set somewhere for an unrelated reason.

Test plan

• New test file extractVideosStage.ffmpegTimeout.test.ts (mirrors the existing extractVideosStage.timelineBound.test.ts mocking pattern): asserts a non-default ffmpegProcessTimeout override reaches the config object extractAllVideoFrames receives, plus a counter-test confirming the default still passes through unchanged.
• bunx tsc --noEmit clean; oxlint/oxfmt --check clean on both touched files.
• Full extractVideosStage suite (3 files, 27 tests) passes.
• Real revert-and-restore: reverted the fix alone and confirmed both new tests fail with a live reproduction of the exact reported bug (the captured config object has no ffmpegProcessTimeout key at all); restored and confirmed green again.
• Review gate confirmed there's exactly one production call site of extractAllVideoFrames/extractVideoFramesRange (this one), so no sibling config-builder has the same gap, and confirmed both callers of runExtractVideosStage (in-process render and distributed plan()) build their config via resolveConfig() (or a caller-supplied EngineConfig, which is non-optional on this field), so the fix applies uniformly to both paths.