fix(windows): improve yt-dlp filename safety without changing defaults

[blueyi]

Summary

• Add --windows-filenames on Windows so yt-dlp replaces invalid characters before writing files
• Compute --trim-filenames from the output directory length instead of a fixed 180 bytes
• Keep the default output template %(title)s.%(ext)s and metadata sidecar naming unchanged

Narrow follow-up to #97 per maintainer feedback: only harden existing safe filename args, without changing default templates, ASCII restrictions, or settings UI.

Test plan

• cargo test filename --lib
• cargo check
• bun run tsc -b
• Facebook Reel with long caption on Windows (previously Errno 22)
• YouTube with non-ASCII title keeps Unicode filename
• Metadata export (description / info.json / comments) still works

[vanloctech]

Thanks, this PR looks much better scoped than the previous filename change. I’m okay with the overall direction: keeping the existing output template, avoiding new settings UI, and only hardening the backend filename safety path is the right approach.

Two small changes before merge:

1. Since the current default trim limit is 180, could we keep the effective cap at 180 instead of increasing short output paths to 200? That keeps the fix more behavior-preserving while still solving the Windows long-path case with path-aware trimming.

2. --trim-filenames is byte-oriented, but calc_trim_filenames_bytes() currently uses output_path.chars().count(). Could we use byte length instead, e.g. output_path.as_bytes().len(), so paths with non-ASCII folder names are handled more conservatively?

After those two small adjustments, this should be good to merge.

[blueyi]

Thanks, this PR looks much better scoped than the previous filename change. I’m okay with the overall direction: keeping the existing output template, avoiding new settings UI, and only hardening the backend filename safety path is the right approach.

Two small changes before merge:

1. Since the current default trim limit is 180, could we keep the effective cap at 180 instead of increasing short output paths to 200? That keeps the fix more behavior-preserving while still solving the Windows long-path case with path-aware trimming.
2. --trim-filenames is byte-oriented, but calc_trim_filenames_bytes() currently uses output_path.chars().count(). Could we use byte length instead, e.g. output_path.as_bytes().len(), so paths with non-ASCII folder names are handled more conservatively?

After those two small adjustments, this should be good to merge.

Done — capped trim at 180 and switched path length to byte count. Thanks for the review!