[Bug]: Uploaded files are saved with garbled non-ASCII names and overwrite existing files with the same name #458

Bug Description

Files sent from the phone with Send File don't always end up on the host the way they were sent:

1. Non-ASCII file names are garbled. résumé.pdf is saved as résumé.pdf, and 照片.jpg as ç§ç.jpg. Browsers send the multipart filename as raw UTF-8, but parseMultipart in src/server/signalling/handlers/fileShare.ts reads the part headers from body.toString("binary") (latin1), so every multi-byte character turns into mojibake.

2. Uploading a file with an existing name silently overwrites the old one. handleFileUpload calls fs.promises.writeFile(path.join(uploadDir, safeName), data), which replaces whatever is already there. This is easy to hit from a phone: iOS Safari names every camera photo image.jpg, so sending two photos leaves only the second one in ReinShared, with no warning.

Steps to Reproduce

1. Run Rein and open the trackpad page on a phone.
2. Send a file named résumé.pdf via Send File → it appears in ~/Downloads/ReinShared as résumé.pdf.
3. Send a photo from the iOS camera roll (image.jpg), then send a different one → only one image.jpg exists, containing the second photo.

I also reproduced both against handleFileUpload directly with a local HTTP server and Node's FormData (which encodes file names the same way browsers do):

on disk: [ 'image.jpg', 'résumé.pdf', 'ç§ç.jpg' ]
image.jpg contents: second photo

Expected Behavior

• The file is saved with the exact name it was sent with.
• If a file with that name already exists, the new one is saved next to it (e.g. image (1).jpg) instead of replacing it.

Desktop Operating System

All (the logic is in the platform-independent fileShare.ts)

Client OS and browser

All (any browser sends UTF-8 filenames; iOS Safari's image.jpg naming makes the overwrite very common)

Rein Version

main @ 4efa9a8

Proposed fix

• Decode the part header bytes as UTF-8 (body.subarray(headerStart, headerEnd).toString("utf8")). The latin1 string is still fine for finding offsets, since its indices match byte positions.
• Write with the wx flag and fall back to name (1).ext, name (2).ext, … on EEXIST, which also avoids two simultaneous uploads racing for the same name.
• Add a test file for the upload handler covering both cases.

I'd like to work on this.