Windows: captions render fails — drive-letter colon in drawtext fontfile breaks the filter chain

Bug: On Windows, "Cut" renders the flat clip but captions are always skipped with:

ffmpeg clip render failed: [AVFilterGraph] No option name near '/Windows/Fonts/SegoeUIb.ttf:text=...'
Error parsing filterchain 'crop=...,drawtext=fontfile='C:/Windows/Fonts/SegoeUIb.ttf':text=...' around: ...

Root cause: build_drawtext_filters in src-tauri/src/lib.rs emits fontfile='C:/Windows/Fonts/SegoeUIb.ttf'. In ffmpeg, drawtext options are :-delimited, and the drive-letter colon in C: terminates the fontfile value early (the surrounding quotes do not protect it on this ffmpeg build). The parser then sees /Windows/Fonts/... as a new option with no =, producing "No option name near ...". macOS/Linux font paths have no drive-letter colon, which is why captions only break on Windows.

Fix (2 lines, verified): escape the colons in the font path:

let escaped_path = normalized_path
    .replace(':', "\\:")
    .replace('\'', "'\\''");
font_option = format!("fontfile='{}':", escaped_path);

This produces fontfile='C\:/Windows/Fonts/SegoeUIb.ttf': which parses and renders correctly (verified end-to-end with ffmpeg 8.1.1 full build on Windows 10/11: the full 52-caption chain renders with exit 0, captions burned in).

Secondary (cosmetic): when a re-cut later succeeds, the clip card still shows the previous failure's render_log — the success path doesn't clear it, which makes it look like the failure persists. Suggest clearing render_log on success.

Start in src-tauri/src/lib.rs at build_drawtext_filters and reproduce the Windows caption render with the reported font path and ffmpeg error. Verify that the full caption chain renders successfully on Windows, then check the successful re-cut path to confirm whether the previous render_log is cleared.