fix(producer): copy extracted frames on Windows to avoid symlink EPERM [P0]

[miguel-heygen]

Problem

Local video renders on Windows without Developer Mode/Administrator fail at the video_extract stage: renderOrchestrator → runExtractVideosStage materializes each video's extracted frames into the compiled dir via symlinkSync with no materializeSymlinks flag, and symlinkSync throws EPERM there. Reported repeatedly (users worked around it by patching cli.js to pass materializeSymlinks: process.platform==='win32', or by falling back to snapshot-frame + manual ffmpeg mux).

The distributed plan() path already copies (materializeSymlinks: true) — only the local render caller was missing it.

Fix

Pass materializeSymlinks: shouldCopyExtractedFrames(process.platform) at the local runExtractVideosStage call in renderOrchestrator.ts:

• win32 → copy the frames (symlinks need privilege there)
• darwin/linux → symlink (cheap; unchanged)

New pure shouldCopyExtractedFrames(platform) helper in extractVideosStage.ts documents the rationale and is unit-tested. This sidesteps the symlink entirely on Windows — independent of, and complementary to, the EPERM→cpSync fallback in open PR #1959 (which catches the throw if a symlink is ever attempted elsewhere).

Tests

extractVideosStage.test.ts — shouldCopyExtractedFrames: win32 → copy (true), darwin/linux → symlink (false). Pre-commit typecheck + fallow + oxlint/oxfmt all green.

[vanceingalls]

R1 — #2025 at 14ece7e532ba2ac4c5376467342a7b28e0dd03a5

🟢 LGTM. Small, well-scoped, correct. Two flags: one required-check blocker, one cosmetic nit.

Correctness

• materializeSymlinks?: boolean is a pre-existing field on ExtractVideosStageInput (verified at head, extractVideosStage.ts:~74 — the doc comment already explains why the distributed plan() path forces true). The local renderOrchestrator caller was the only site that omitted it, silently defaulting to false → symlinkSync → EPERM on Windows without Dev Mode. This PR wires the flag through cleanly.
• Helper is pure and platform-string-driven — trivial to unit test, trivially correct. Naming is a bit meta (shouldCopyExtractedFrames returns the value we pass as materializeSymlinks), but the two names semantically agree so it's fine.
• Complementary to open PR #1959 (EPERM → cpSync fallback inside the extract stage itself): this PR sidesteps the symlink preemptively on win32; #1959 catches at throw-time. They compose well — this one covers the intended path, #1959 catches any escape.

Coverage

Helper unit-tested for the three relevant platforms. The orchestrator wiring is validated by the Windows render verification CI job (SUCCESS on the older SHA at 18:32; re-triggered at 19:03 for the current head, Render on windows-latest still IN_PROGRESS at review time — worth waiting for green before merge).

Blocker

• Semantic PR title CI check FAILED on the current head (SUCCESS on the earlier SHA at 18:24, FAILURE at 19:02). The [P0] prefix breaks conventional-commits parsing. Either drop the prefix from the title (keep the body as-is), or move the [P0] marker to the end / a label. If this is a required check, it'll block merge.

Optional nit

• Windows users who have Developer Mode or admin enabled don't need the copy — symlinkSync would work for them, and copying is measurably slower for large extractions. This PR always copies on win32 regardless. Right call for now (correctness > perf, and detecting Dev Mode is a syscall dance you'd rather not add here), but worth remembering if the copy step ever shows up in perf profiles from win32 users.

R1 by Via

[miguel-heygen]

@via thanks for the review. The semantic-title check was failing on the [P0] prefix — moved the priority tag to the end of the title so it parses as a conventional commit again (green now). No code change. Agree on letting the windows-latest render job go green before merge; it was mid-run at the new head.