fix(export): stop silently dropping audio when source track extraction fails

[davidy1402]

Problem

Fixes #26.

Exporting a long recording (~8 min) produced an MP4 with no audio track at all, while short clips exported fine and the editor preview played audio correctly. The source recording contains a valid mono 44.1 kHz AAC track.

Root cause: during export, audio is re-extracted from the source file via mediabunny. When both the UrlSource and the BlobSource (fetch().blob()) reads fail — which happens with large file:// sources — resolveSourceAudioTrack() logged a console warning and silently continued with a video-only export. The user only discovers the missing audio after a long, CPU-intensive export.

I verified the failure is in the fetch layer, not the file: parsing the exact same 263 MB recording with mediabunny's BufferSource from raw bytes finds the AAC track instantly.

Changes

• New read-current-video-bytes IPC channel (main + preload + type defs): lets the renderer read the current video's bytes directly from disk through the main process. Only the already-registered currentVideoPath can be read — the renderer cannot pass arbitrary paths.
• Third extraction fallback: resolveSourceAudioTrack() now tries UrlSource → BlobSource → BufferSource (via the new IPC channel), so audio extraction succeeds even when fetch(file://) misbehaves on large files.
• Fail loudly instead of silently degrading: if every extraction attempt errors, the export now aborts with a clear error before frame rendering starts, instead of spending minutes producing a silent video. A source that parses fine but genuinely has no audio track still exports video-only with the existing editor.exportWarningAudioTrackUnavailable warning.
• Regression tests for the fallback chain (5 new tests in videoExporterAudio.test.ts).

Testing

• npx tsc --noEmit — clean
• npx vitest --run — 169/169 tests pass
• Built the patched app locally (npm run build:mac) and confirmed the fix ships in the bundle

🤖 Generated with Claude Code