fix(operations): sanitize FAT-invalid names instead of discarding the copy

[pdwaldrop]

Description

Copying a directory onto a FAT/exFAT/vFAT destination (a USB stick, most commonly) failed outright with "Invalid filename" as soon as any nested entry's name contained a character those drivers reject (" * / : < > ? \ |, or a control character) — and since the transfer stages into a temporary sibling directory first, the whole staged copy was discarded on that one failure, even after a large amount had already been written. Pasting a single file with such a name failed the same way.

Mirrors GNOME Files' behavior: when the destination reports a FAT-family filesystem type (checked once per transfer against the parsed mount table, not per file), rejected characters are replaced with _ and trailing dots/spaces are trimmed (the drivers strip these anyway). Sibling names that collapse to the same result after sanitizing get a numbered suffix (name (1).ext) instead of one silently overwriting the other. This applies to the top-level paste target and every nested copy path: the recursive copy itself, move's cross-filesystem WouldRecurse fallback, replace, and merge.

Non-FAT destinations are completely unaffected — verified with a dedicated regression test.

Visual evidence

N/A — this only changes filename handling during file transfers; there is no UI-visible change.

How to test

1. Create a folder containing a file with a FAT-invalid name, e.g. mkdir demo && touch 'demo/a?b:c.txt' demo/ok.txt.
2. Mount an exFAT (or vfat) test volume, e.g. truncate -s 256M fat.img && mkfs.exfat fat.img && udisksctl loop-setup -f fat.img.
3. In Strata, copy demo and paste it onto the mounted volume.

Expected result: the folder is copied in full; a?b:c.txt lands as a_b_c.txt instead of the whole transfer failing and being discarded. Pasting a single file with an invalid name onto the same volume also succeeds, sanitized the same way.

Local validation note: this machine has no docker/podman set up, so the pinned ./scripts/quality.sh container runner wasn't available — used plain host cargo fmt --all --check / cargo clippy --all-targets --all-features -- -D warnings instead (both clean), plus ./scripts/test-headless.py for the full adapters::local_operations:: and adapters::volume:: suites (all passing; two pre-existing, unrelated archive-compression test failures were confirmed present on unmodified main too, via git stash, before ruling them out as caused by this change).

Related issue

Closes #1123