For Quality

This PR changes real upload mechanics (not just a UI overlay) on the S3 route, so functional regression there is the highest-value area to test — a broken upload is much worse than a wrong percentage.

Core functional checks (both storage routes)

Run each of the four flows below against a company without Google Drive connected (S3 route) and, separately, a company with it connected (Drive route) — they go through different code in handleUploadFile.js and should be verified independently:

1. Clock in with a photo (ClockScreen.js)
2. Clock out with a photo
3. Add a patient file — try a photo, a document, and a screenshot

(NewFileScreen.js)

1. Record and save a patient voice note (NewNoteScreen.js)
2. Record and send a voice message in staff chat (AudioRecordingButton.js)

For each: confirm the file actually uploads and is retrievable afterward (not just that the progress UI looked right) — the S3 route changed from a fetch/FormData POST to expo-file-system's createUploadTask multipart POST, which is a genuine behavior change, not a pure refactor.

Progress-display edge cases

• Large file, slow/throttled connection — confirm the percentage climbs

smoothly and the speed line appears after ~0.3s and updates, rather than jumping straight to 100%.

• Very small/fast upload — confirm it doesn't get stuck showing 0%/no detail

forever if the platform never fires an intermediate progress event; complete() should force it to 100% on success regardless.

• Airplane mode / connection drop mid-upload — confirm the percentage stops

climbing and the speed line disappears (rather than showing a stale, still-moving speed) — see useUploadProgress.js:78, which requires elapsed time and nonzero sent bytes for a speed to render.

• Multiple files in one batch, if the UI supports selecting several patient

files at once — confirm the percentage reflects combined bytes sent across the whole batch, not one file's progress reused across all of them (useUploadProgress.js:74-76).

• Recording flows (voice note, voice message, clock-in photo) — confirm the

spinner shows no percentage for a brief moment at the very start (size is unknown until the recording is made and the upload begins), then fills in.

• Cancel/error during upload — confirm upload.end() still runs (it's in every

screen's finally block) so the next upload's start() resets state correctly instead of inheriting stale in-flight state.

Things that look like bugs but likely aren't

• The clock-in photo's percentage may jump shortly after starting — its initial

size estimate (imageSrc.base64.length * 4 in ClockScreen.js) is a rough overestimate corrected once the platform reports the real total. Confirm it does correct and settle, rather than staying wrong.

• The system chat voice message spinner only shows a percentage, never a size/speed

line — that's intentional (AudioRecordingButton.js:188 only passes progress), not a missed wiring.

Out of scope for this PR

• No server/API changes — don't expect anything different in server logs, Prisma

models, or GraphQL schema related to this.

• No changes to file size limits, allowed file types, or storage location.
• No web dashboard changes — clinic-web's upload UI is untouched.