perf(recording): stream native Windows screen recording to main process without renderer round-trip

[coderabbitai]

Summary

Currently, the native Windows finalize path (finalizeNativeWindowsRecording in src/hooks/useScreenRecorder.ts) reads the entire on-disk screen recording back into renderer memory via window.electronAPI.readBinaryFile(nativeScreenPath) and ships those bytes to the main process via storeRecordedSession. For long recordings this can be a multi-GB IPC transfer and risks an OOM crash in the renderer on stop — even after the webcam sidecar OOM fix in #687.

Proposed fix

Add a dedicated main-process IPC handler (e.g. attach-webcam-to-screen-recording) that accepts:

• The native screen file path (already on disk)
• The webcam sidecar file name / whether it is streamed
• A small duration-fixed webcam blob buffer (only when not streamed)

The main process reads, patches, and merges the files itself — the renderer never marshals the multi-GB screen bytes over IPC.

Context

• Pre-existing limitation, not introduced by fix(recording): stream native-capture webcam to disk to prevent OOM crash on stop #687.
• fix(recording): stream native-capture webcam to disk to prevent OOM crash on stop #687 eliminated the webcam sidecar OOM by streaming it to disk; this issue tracks the analogous fix for the screen recording.
• Discussed in: fix(recording): stream native-capture webcam to disk to prevent OOM crash on stop #687 (comment)
• Related PR: fix(recording): stream native-capture webcam to disk to prevent OOM crash on stop #687

Acceptance criteria

• readBinaryFile(nativeScreenPath) is removed from the renderer finalize path
• A main-process handler owns the screen + webcam disk merge/patch
• Renderer only marshals small in-memory webcam data (if any)
• Existing tsc --noEmit, biome check, and vitest checks remain green