fix(producer): decode percent-encoded video src in HDR pre-extract

[vanceingalls]

Fixes symptom (c) of PRINFRA-349 (non-ASCII / CJK media path breaks HDR render).

Root cause

HDR pre-extraction resolved a <video> source to a filesystem path by naively joining the raw src attribute:

let srcPath = v.src;
if (!srcPath.startsWith("/")) {
  srcPath = existsSync(join(compiledDir, srcPath)) ? join(compiledDir, srcPath) : join(projectDir, srcPath);
}

But v.src is the compiled DOM's URL attribute, so a source named 视频1.mp4 arrives percent-encoded as %E8%A7%86%E9%A2%911.mp4. That encoded string was passed straight to ffmpeg as a path → Error opening input file <project>/%E8%A7%86%E9%A2%911.mp4: No such file or directory. The SDR extractor never hit this because it resolves through resolveProjectRelativeSrc, which tries decodeUrlPathVariants against the filesystem; the HDR planner had its own hand-rolled join that skipped the decode.

Fix

planHdrResources now resolves via the shared resolveProjectRelativeSrc — the exact resolver the SDR path uses — so the encoded src decodes back to the real on-disk filename (and query strings, origin-root URLs, and .. traversal now resolve identically across the two paths). Removed the redundant injected existsSync param.

Test

• New planHdrResources tests: a percent-encoded CJK src resolves to the decoded on-disk path; an ASCII src is unchanged. (captureHdrResources.test.ts, 5/5)
• tsc / oxlint / oxfmt clean.

Scope note

The ticket aggregates three symptoms under "one root cause," but (c) is independent of (a)/(b): it's a cross-platform URL-vs-filesystem decode bug in the producer (reproduces on macOS, per the report), not Windows-native path handling. (a) Windows init access-violation and (b) Windows init EIO are a separate Windows-native theme — see the ticket comment for triage; they need a Windows repro to fix safely and aren't touched here.

Related: PRINFRA-349

🤖 Generated with Claude Code