fix(recording): keep Windows screen frames in sync

[hyuhan666-art]

Summary

This PR stabilizes Windows screen recordings by keeping encoded screen frames close to the latest captured frame instead of preserving a stale backlog.

Root cause

On Windows, the screen-frame channel could buffer several seconds of frames under encoder or muxer backpressure. Cursor events continued to follow wall-clock recording time, while the video encoder could still be consuming older screen frames. That made exported recordings look like the cursor was ahead of the screen content, and it also made recordings feel laggy under load.

Windows multi-segment studio recordings also already use recording-epoch timestamps for video packets. Applying latest_start_time again during rendering double-counted capture startup delay and could push the rendered cursor ahead of the screen.

What changed

• Reduce the default Windows muxer buffer size from 240 frames to 8 frames.
• Drain stale queued screen frames and encode the latest available frame in Windows output pipelines.
• Make fragmented/OOP video frame handoff use non-blocking sends so backpressure drops stale frames instead of blocking capture.
• Skip macOS-style latest_start_time offset for Windows multi-segment studio recordings.
• Include crates/recording in the desktop sidecar rebuild dependency list so recording pipeline changes rebuild the binary.

Validation

• cargo fmt --all --check
• cargo check -p cap-recording --lib
• cargo test --lib -p cap-rendering -p cap-project -p cap-recording