fix: CSP worker-src blocking editor video/camera preview

[Alfredoalv13]

Summary

• After a recording finished and the editor opened, the video and camera preview showed nothing at all (audio played, but no video/canvas rendering) - this is a regression from the original webSecurity/CSP hardening PR, not the recording pipeline itself.
• Root cause: no worker-src was declared in the CSP, so Chromium fell back to script-src for the waveform/decode workers the editor creates from blob: URLs. script-src doesn't allow blob:, so worker creation threw a CSP violation, severe enough to abort the surrounding media-loading sequence entirely.
• Fix: add an explicit worker-src 'self' blob: <allowed origins> directive.

A security note on scope

The console also showed connect-src violations for sidecar audio files (fetch('file://.../recording.system.wav') etc.). I initially widened connect-src to allow file: broadly to silence those too, but reverted that after checking RECORDINGS_DIR is already an allowed prefix for the proper getLocalMediaUrl() media-server path, and the sidecar-probing code (useTimelineAudioPeaks.ts) already retries per-candidate on any failure - so those specific file:// fallback fetches failing is harmless. Broadening connect-src to file: renderer-wide would have let any compromised renderer code (a bad extension, XSS) read arbitrary local files directly via fetch(), bypassing every path allowlist fixed in the original security review - to fix a symptom the worker-src fix alone already resolves.

Test plan

• tsc --noEmit clean
• npm test - 94/94 files, 817/817 tests passing
• Verified in a debug build: loaded a known-good recording directly, confirmed every CSP violation is gone and the main video load no longer aborts (previously net::ERR_ABORTED)
• Manual: record something, confirm the editor preview actually shows the video and camera feed