Browser uploads carry no checksum, so damaged or spliced uploads are stored silently #3530

Initial Checklist

• I understand this is a bug report and questions should be posted in the Community Discussions
• I searched issues and couldn’t find anything (or linked relevant results below)

Bug Description

Uploads from the web client carry no checksum. TUS_ALLOWED_META_FIELDS in
packages/web-pkg/src/services/uppy/uppyService.ts is ['name', 'mtime'], and the XHR
(plain PUT) fallback sends no OC-Checksum header. The server verifies a checksum entry
in the tus Upload-Metadata ('<algorithm> <hex>') and an OC-Checksum header on PUT, but
without one it cannot tell a damaged upload from a good one.

This also affects resumes: tus-js-client resumes from localStorage by name, type, size,
last-modified time and endpoint. A different file matching all of these resumes the first
file's partial upload, and the stored file is the two files spliced together.

Reproduction Steps

1. Pick two different files with the same name, size and last-modified time.
2. Start uploading the first one in the browser and cut the connection after the first chunk.
3. Upload the second one to the same folder.
4. Download the result.

(Server-side races that duplicate bytes, such as overlapping PATCH requests, are equally
undetected for browser uploads.)

Expected Outcome

The upload is rejected because its content does not match a checksum of the file, and the
user sees the upload fail.

Actual Outcome

The upload succeeds and the stored file contains the first file's beginning and the second
file's end. (Derived from tus-js-client's fingerprint resume and the missing checksum; with
the checksum in the linked PR, the same steps in a headless browser end with the upload
rejected (460) and nothing stored.)