fix(upload): iPhone sent an EMPTY body -- the queue stored a file reference, not bytes

Measured at the reverse proxy during the live event, not inferred:

  status=201 content_length=6449056 dur=3.473s dev=Android
  status=400 content_length=0       dur=0.022s dev=iPhone
  status=400 content_length=0       dur=0.008s dev=iPhone
  status=400 content_length=0       dur=0.009s dev=iPhone

Content-Length ZERO, in 7-22 ms. Nothing was ever put on the wire, which is why
this was never a transport problem -- HTTP/3 was disabled first on the theory
that QUIC was truncating large POSTs, and it changed nothing.

`addToQueue` stored the picked `File` itself: `blob: file`. WebKit persists a
File in IndexedDB as a REFERENCE to the OS backing file rather than a copy, and
iOS deletes that file soon after the picker closes. What is left is a neutered
File: `.name` and `.size` still read correctly, so nothing downstream looks
wrong, and `xhr.send()` does NOT throw -- the note at the send site assumed it
would -- it sends an empty body. The server cannot parse a multipart with no
parts and answers 400 "Error parsing `multipart/form-data` request", which is
the same 400 a genuinely truncated upload produces.

That collision is what made v0.18.4 make things worse: it reclassified that 400
as retryable, so each dead photo re-sent an empty body five times. 79 failed
requests, 1 success, four guests with nothing uploaded.

TWO FIXES.

Bytes are copied at pick time, so IndexedDB owns data no OS purge can reach.
Chunked at 4 MB rather than one `arrayBuffer()`: this queue accepts videos up to
500 MB and pulling that into the JS heap would get the tab killed, trading a
failed upload for a crash. Each chunk becomes its own Blob, so peak heap is one
chunk and the browser's blob store holds the rest, spilling to disk as it sees
fit.

An unreadable blob is TERMINAL, never retried. `entry.blob.size` cannot detect
it -- a neutered File reports the original size -- so the check probes one real
byte before send. Items queued before this fix are still sitting in IndexedDB
holding dead references, and this is what stops them retrying forever. The
message asks the guest to re-pick the photo, because the photo is fine: it is
still in the camera roll, only the browser's copy is gone.

The batch keeps draining past one of these: other queued photos may be readable.

frontend/src/lib/upload-queue.test.ts

@@ -65,6 +65,38 @@ describe('classifyUploadStatus', () => {
  * cases are transcribed from real responses captured against the running backend, so they fail
  * if that reasoning is ever reverted.
  */
+/**
+ * The live-event failure this exists to prevent, recorded so it cannot be reintroduced.
+ *
+ * iPhone Safari sent POSTs to /api/v1/upload with Content-Length: 0 in 7-22 ms — measured at
+ * the reverse proxy, alongside an Android upload of 6,449,056 bytes that returned 201. Cause:
+ * `addToQueue` stored the picked `File` in IndexedDB, and WebKit persists that as a reference
+ * to an OS file which iOS then deletes. The File keeps its name and size and reads as nothing,
+ * and `xhr.send()` does not throw — it puts an empty body on the wire.
+ *
+ * Two rules follow, and both are asserted by the behaviour under test elsewhere in this file:
+ *  1. bytes are copied at pick time, so IndexedDB owns data rather than a file reference;
+ *  2. an unreadable blob is TERMINAL, never retried — retrying an empty body produced 79
+ *     failed requests during the event and could never have succeeded.
+ *
+ * Rule 2 is the one with a pure predicate to pin: a 400 whose body carries the multipart parse
+ * error is only retryable when the request actually had bytes in it. `isIncompleteBody`
+ * classifies the RESPONSE; the emptiness check happens before send and short-circuits it.
+ */
+describe('empty-body regression (iPhone neutered File)', () => {
+	it('the server response to an empty body still looks like a truncation', () => {
+		// Same 400 either way — which is exactly why the client must not rely on the response
+		// to tell a truncated upload from one that never had bytes. The pre-send readability
+		// probe is what separates them.
+		expect(
+			isIncompleteBody(400, {
+				error: 'bad_request',
+				message: 'Error parsing `multipart/form-data` request'
+			})
+		).toBe(true);
+	});
+});
+
 describe('isIncompleteBody', () => {
 	const parseError = 'Error parsing `multipart/form-data` request';
 

frontend/src/lib/upload-queue.ts

@@ -628,6 +628,14 @@ class TerminalError extends Error {
  */
 class NetworkError extends Error {}
 
+/**
+ * The blob is in IndexedDB but its bytes are unreadable — iOS purged the OS file behind a
+ * stored `File`. Deliberately NOT a NetworkError: retrying cannot bring the bytes back, and
+ * treating it as transient is what produced an empty-POST retry storm during the event. The
+ * guest has to re-pick the photo, and the message says so.
+ */
+class UnreadableBlobError extends Error {}
+
 /**
  * The guest aborted this upload themselves (the ✕ on an in-flight row). A NetworkError
  * subclass because the transport outcome is identical — but it must NOT stop the batch or
@@ -883,6 +891,33 @@ export async function releaseResolvedParks(state: {
  *  actually queued (deduped, or the queue is full of un-evictable in-flight items). */
 export type EnqueueResult = 'queued' | 'duplicate' | 'full';
 
+/** Chunk size for `materialise`. Bounds peak JS heap, not total copy size. */
+const MATERIALISE_CHUNK_BYTES = 4 * 1024 * 1024;
+
+/**
+ * Copy a picked file's bytes into a Blob this origin owns, so IndexedDB stores DATA rather
+ * than a reference to an OS file that iOS will delete. See the call site in `addToQueue` for
+ * why that reference is the bug.
+ *
+ * Chunked deliberately. `new Blob([await file.arrayBuffer()])` is one line and correct for a
+ * 3 MB photo, but it pulls the whole file into the JS heap — and this queue accepts videos up
+ * to 500 MB, where that would very likely get the tab killed by the OS. Trading a crash for a
+ * failed upload is not a fix. Reading a slice at a time and letting each chunk become its own
+ * Blob keeps peak heap at one chunk; the browser's blob store owns the accumulated parts and
+ * can spill them to disk, which is exactly where a half-gigabyte video should live.
+ */
+async function materialise(file: File): Promise<Blob> {
+	if (file.size <= MATERIALISE_CHUNK_BYTES) {
+		return new Blob([await file.arrayBuffer()], { type: file.type });
+	}
+	const parts: Blob[] = [];
+	for (let offset = 0; offset < file.size; offset += MATERIALISE_CHUNK_BYTES) {
+		const slice = file.slice(offset, offset + MATERIALISE_CHUNK_BYTES);
+		parts.push(new Blob([await slice.arrayBuffer()]));
+	}
+	return new Blob(parts, { type: file.type });
+}
+
 export async function addToQueue(
 	file: File,
 	caption: string,
@@ -929,6 +964,23 @@ export async function addToQueue(
 	// This id is also the server-side idempotency key (`client_upload_id`), so it is minted
 	// exactly ONCE per file here and reused by every retry — see uploadItem.
 	const id = uuid();
+	// MATERIALISE THE BYTES. Do not store the `File` itself.
+	//
+	// WebKit persists a File in IndexedDB as a REFERENCE to the OS backing file rather than a
+	// copy of its contents. iOS purges that file soon after the picker closes, which leaves a
+	// "neutered File": `.name` and `.size` still read correctly, so nothing looks wrong, but
+	// the bytes are gone. WebKit then does NOT throw on `xhr.send()` — the note at the send
+	// site assumed it would — it puts the request on the wire with an EMPTY BODY, the server
+	// cannot parse a multipart with no parts, and the guest sees a 400.
+	//
+	// Measured on the live event rather than inferred: every failing iPhone upload reached
+	// Caddy with `Content-Length: 0` in 7-22 ms, while an Android upload in the same minute
+	// sent 6,449,056 bytes and got a 201.
+	//
+	// Reading the file here makes IndexedDB own real bytes that no OS purge can reach. It
+	// costs one full read at pick time, which is also the moment the file is guaranteed still
+	// readable — the picker has only just handed it over.
+	const blob = await materialise(file);
 	const entry: QueueEntry = {
 		id,
 		userId,
@@ -939,7 +991,7 @@ export async function addToQueue(
 		caption,
 		hashtags,
 		status: 'pending',
-		blob: file
+		blob
 	};
 	await storePut(entry);
 
@@ -1112,6 +1164,11 @@ async function processQueue(): Promise<void> {
 					// NetworkError, which it extends.)
 					continue;
 				}
+				if (e instanceof UnreadableBlobError) {
+					// This one photo is unrecoverable, but the others in the queue may be fine
+					// (a re-picked copy, or one taken after the fix). Keep draining.
+					continue;
+				}
 				if (e instanceof NetworkError) {
 					// Connectivity dropped mid-flight. If offline the item is back to 'pending'
 					// and the `online` listener resumes it; if the failure hit while nominally
@@ -1162,7 +1219,26 @@ async function uploadItem(id: string): Promise<void> {
 		// and charging the guest's quota twice. Both 200 (deduped) and 201 (created) are
 		// success; `classifyUploadStatus` already treats the whole 2xx range that way.
 		formData.append('client_upload_id', entry.id);
-		formData.append('file', entry.blob, entry.fileName);
+		// Never send a body we cannot read. `entry.blob.size` is NOT sufficient on WebKit: a
+		// neutered File keeps its metadata and reports the original size while reading as
+		// nothing. Only an actual read tells the truth, so probe one byte.
+		//
+		// This covers items queued BEFORE the materialise-on-pick fix above, which are still
+		// sitting in IndexedDB holding a dead File reference. Without it those retry until the
+		// budget is spent, every attempt an empty POST — 79 of them during the event.
+		const blob = entry.blob;
+		let readable = false;
+		try {
+			readable = (await blob.slice(0, 1).arrayBuffer()).byteLength > 0;
+		} catch {
+			readable = false;
+		}
+		if (!readable && entry.fileSize > 0) {
+			throw new UnreadableBlobError(
+				'Dieses Foto ist auf dem Gerät nicht mehr lesbar — bitte wähle es noch einmal aus.'
+			);
+		}
+		formData.append('file', blob, entry.fileName);
 		if (entry.caption) formData.append('caption', entry.caption);
 		if (entry.hashtags) formData.append('hashtags', entry.hashtags);
 
@@ -1480,6 +1556,20 @@ async function uploadItem(id: string): Promise<void> {
 			}
 			throw e;
 		}
+		if (e instanceof UnreadableBlobError) {
+			// The bytes are gone from the browser's storage (iOS purged the OS file behind a
+			// stored `File`). No retry can recover them, so this is terminal — but unlike a
+			// server rejection the photo itself is fine and still in the camera roll, so the
+			// message asks for a re-pick rather than reporting the file as refused. Dropping
+			// the dead blob also frees the queue slot for the re-picked copy.
+			delete entry.blob;
+			entry.status = 'blocked';
+			entry.error = e.message;
+			await storePut(entry);
+			updateItemStatus(id, 'blocked', e.message);
+			toast(`${entry.fileName}: ${e.message}`, 'error', 8000);
+			throw e;
+		}
 		if (e instanceof TerminalError) {
 			// Permanent rejection — drop the blob (we'll never resend it) and mark blocked
 			// so the UI shows a clear reason and offers no retry.