fix(remotion): unblock local zero-key rendering

[ketpatil77]

Summary

• fix Explainer local asset resolution so file:// and absolute Unix/Windows paths stay valid Remotion URIs
• normalize local narration/music paths before writing Remotion props
• mark Piper as DEGRADED when no voice model is installed and surface current piper.download_voices guidance

Testing

• C:\Users\Jayesh\AppData\Local\Programs\Python\Python314\python.exe -m pytest tests\tools\test_remotion_local_asset_paths.py tests\tools\test_remotion_diagnostics.py tests\contracts\test_phase3_contracts.py -k "PiperTTS or remotion"

[calesthio]

Thanks for tackling the local zero-key rendering path. The Piper status direction is useful, but I’m requesting changes because the Remotion portion is an older partial approach that does not solve the render-time local asset failure described in the PR family.\n\nThe current diff normalizes local cuts and audio to ile:// URIs. However Remotion’s renderer rejects local ile:// resources and only reliably loads http(s) URLs or assets served from the composer public/ directory. That is why #238 moved to staging local assets into
emotion-composer/public/_om_assets and rewriting props to staticFile-relative paths. Keeping this PR as-is would still let local images/video/audio fail at render time despite the props looking normalized in the test.\n\nThere is also substantial overlap with #238, which already contains the broader staging work, stale-copy refresh, cinematic audio staging, and Piper voice resolution follow-ups. Please rebase this on the current rendering fix direction or close it in favor of #238 after its remaining Piper executable-status contract is fixed.\n\nI did not find a separate security issue here; this is a correctness/scope issue around the Remotion asset-loading contract.