fix: webcam recording truncates to a fraction of a second (camera stream contention)

[Alfredoalv13]

Summary

• Verified with real recorded output from this session: a screen recording that ran 15.3 seconds paired with a webcam file only 0.12 seconds long. The camera track died almost immediately after recording started.
• This is the exact failure mode PR fix: surface silent failures in the post-recording finalization pipeline #5 added detection/toast for ("Your webcam stopped responding during this recording") - that PR surfaced the symptom but didn't address why it was happening.
• Root cause: the floating live-preview bubble (useWebcamPreviewOverlay) and the actual recording (useScreenRecorder) each independently call getUserMedia() for the same physical camera, at different resolutions, and both run concurrently for the entire recording (the bubble stays visible throughout). Two concurrent capture sessions on one camera is fragile on many devices and is what was truncating the recorded file.
• Fix: useScreenRecorder now exposes its active recording stream reactively. The preview attaches directly to that stream when a recording is active, instead of opening a second independent session - falling back to its own getUserMedia() call only when idle. Stream ownership (who calls .stop() on the tracks) stays with whoever actually opened it.

Test plan

• tsc --noEmit clean
• npm test - 94/94 files, 819/819 tests passing
• Manual (important, not covered by unit tests): enable the webcam, start a recording of at least 10-15 seconds, stop it, and confirm in the editor that the webcam layer plays back the full duration rather than freezing/looping near the start. This is exactly the bug PR fix: floating webcam preview gets clipped/stuck in HUD passthrough-fallback mode #17 was adjacent to (webcam preview overflow) and the one reported in the same test session.