Bug: `unzip -t` report errors when the archived filenames contain symbol characters.

### Description

As the picture shows, the same files separately compressed by `Files - Preview - 4.0` and `Bandizip` into `.zip` archives. Then using `unzip -t` command to test data, `Files` compressed one detected error whereas `Bandizip` didn't.

This can be quite panic and inconvenient on managing a large number of archive files. Because when you suspect that some files may be corrupted due to hardware failure or improper transfer, then you using `unzip -t` to check all the nested folders' archives, this warning-error messages are very annoying, turning out not the data corrupted but the filenames contain symbol characters like `×`. This makes it harder to identify which files are actually corrupted.

By the way, this has been happening since I started using `Files`, from version `3.9.1` to the latest `4.0`. It didn't appear only after using UTF-8 compressing in version `4.0`.

### Steps To Reproduce

1. Create text files named as `1920×1080, 2560×1600, 3200×2000`.
2. Select all of them, right click then choose `compress > create xxx.zip`, rename it to `files.zip`; the same files right-click choosing `Bandizip` to compress them into a `.zip` file, rename it to `bandizip.zip`.
3. Open `Git Bash` in `Windows Terminal`, execute `unzip -t bandizip.zip` and `unzip -t files.zip`.

### Files Version

4.0.0.0

### Windows Version

10.0.26100.1742

### User ID

81723aa7-ab09-4d2c-86c2-baa4b7c7d83d

### Log File

[debug.log](https://github.com/user-attachments/files/22087872/debug.log)

Reproduce the issue with filenames containing × using the Files-created and Bandizip-created archives, then compare the `unzip -t` output and inspect the linked debug.log. Done means filename characters no longer produce misleading test errors while genuine archive corruption is still reported.

Written by the indexing model from the issue text.