fix(upload): a truncated body no longer destroys the guest's photo, and the in-app camera can be switched off

Two event-day failures, both frontend-only.

TRUNCATED UPLOADS PURGED THE PHOTO. An iPhone guest uploading from the gallery
inside WhatsApp's browser got "Error parsing `multipart/form-data` request" and
the item went to "Gesperrt" with no retry. That message is AXUM's own multipart
rejection — a plain-text 400, no JSON envelope — which means the request body
never arrived intact. It is a transport failure, not a verdict on the file.

`classifyUploadStatus` maps every 4xx to `terminal`, and terminal PURGES the blob
from IndexedDB and offers no retry. So a webview hiccup deleted the only copy the
guest had, and told them the photo was rejected.

Every 400 the app itself raises carries `bad_request` in a JSON envelope (too
large, wrong type, caption too long, NUL byte), so an unparseable 400 is
distinguishable and is now a NetworkError: blob kept, retry offered. This is the
same rule the 403 branch already applies — "an unparseable body must NOT purge
the blob, losing a photo is the worst outcome" — extended to the status that was
actually hit. Retrying is safe because nothing was parsed, so nothing was stored
and no quota was charged, and `X-Client-Upload-Id` makes a duplicate impossible.

IN-APP CAMERA SWITCH. `PUBLIC_CAMERA_ENABLED=false` removes the "Kamera — Jetzt
aufnehmen" entry from the upload sheet. On some phones `getUserMedia` fails when
switching front/back ("Kamera konnte nicht gestartet werden") or when asked for
video, and those failures are per-device and undiagnosable mid-event; the switch
removes the broken path rather than leaving guests to find it. Nothing is lost:
the gallery picker reaches the phone's own camera app and handles video.

Read at RUNTIME via `$env/dynamic/public`, so flipping it is a compose variable
and `up -d frontend`, not a rebuild. Deliberately NOT routed through the
backend's event payload like `comments_enabled`: that flag describes the event,
this one describes what the client can do — the backend cannot tell a camera
upload from a gallery upload and has no stake in it. Keeping it off the app image
also means no backend release on the day of the event.

The onboarding step and the in-app-browser hint drop their camera wording when it
is off, so no text promises a button that is not there.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

frontend/src/lib/components/OnboardingGuide.svelte

@@ -6,6 +6,7 @@
 	import { scrollLock } from '$lib/actions/scroll-lock';
 	import { vibrate } from '$lib/haptics';
 	import { hasSeenGuide, markGuideSeen } from '$lib/onboarding';
+	import { cameraEnabled } from '$lib/feature-flags';
 
 	type Step =
 		| { kind: 'text'; icon: string; title: string; body: string }
@@ -30,7 +31,13 @@
 			kind: 'text',
 			icon: '⬆️',
 			title: 'Fotos & Videos hochladen',
-			body: 'Tippe auf den Kamera-Button unten in der Mitte, um Fotos aus deiner Galerie zu wählen oder direkt mit der Kamera aufzunehmen. Mehrere Dateien auf einmal sind kein Problem!'
+			// The second half is conditional: with the in-app camera switched off, promising
+			// "direkt mit der Kamera aufnehmen" describes a button that is not there. The
+			// gallery picker still reaches the phone's camera app on both iOS and Android, so
+			// the capability survives — only the in-app shortcut is gone.
+			body: cameraEnabled
+				? 'Tippe auf den Kamera-Button unten in der Mitte, um Fotos aus deiner Galerie zu wählen oder direkt mit der Kamera aufzunehmen. Mehrere Dateien auf einmal sind kein Problem!'
+				: 'Tippe auf den Kamera-Button unten in der Mitte und wähle Fotos oder Videos aus deiner Galerie. Frisch aufnehmen kannst du direkt in der Auswahl deines Handys. Mehrere Dateien auf einmal sind kein Problem!'
 		},
 		{
 			kind: 'text',

frontend/src/lib/components/UploadSheet.svelte

@@ -8,6 +8,7 @@
 	import type { PendingFile } from '$lib/pending-upload-store';
 	import { eventState, uploadsClosed } from '$lib/event-state-store';
 	import { commentsEnabled } from '$lib/event-config-store';
+	import { cameraEnabled } from '$lib/feature-flags';
 	import { isBanned } from '$lib/ban-store';
 
 	// A ban closes uploads just as hard as an event lock does — the backend refuses every
@@ -150,8 +151,12 @@
 	}
 </script>
 
-<!-- Camera (rendered outside sheet so it gets full viewport) -->
-{#if showCamera}
+<!-- Camera (rendered outside sheet so it gets full viewport).
+     `cameraEnabled` is checked here as well as on the button: `showCamera` is ordinary
+     component state, and a belt-and-braces guard means no future entry point (a deep link, a
+     restored state, a stray keyboard shortcut) can mount the capture UI while it is switched
+     off for the event. -->
+{#if showCamera && cameraEnabled}
 	<CameraCapture
 		oncapture={handleCapture}
 		onclose={handleCameraClose}
@@ -262,7 +267,11 @@
 				</div>
 			</button>
 
-			<!-- Camera option -->
+			<!-- Camera option. Hidden entirely when PUBLIC_CAMERA_ENABLED=false: on some devices
+			     `getUserMedia` fails when switching front/back or when asked for video, and a
+			     button that throws an error modal is worse than no button. The gallery entry
+			     above still reaches the OS camera and handles video. -->
+			{#if cameraEnabled}
 			<button
 				onclick={openCamera}
 				class="flex w-full items-center gap-4 rounded-xl bg-gray-50 px-5 py-4 text-left transition hover:bg-gray-100 active:bg-gray-200 dark:bg-gray-800 dark:hover:bg-gray-700 dark:active:bg-gray-600"
@@ -294,6 +303,7 @@
 					<p class="text-sm text-gray-500 dark:text-gray-400">Jetzt aufnehmen</p>
 				</div>
 			</button>
+			{/if}
 
 			<!-- The in-app-browser escape hatch.
 			     The join link travels through WhatsApp groups, and a link tapped inside one opens
@@ -311,8 +321,8 @@
 			     hint they cannot act on into an instruction they can. -->
 			<p class="px-1 pt-1 text-center text-xs text-gray-500 dark:text-gray-400">
 				Nichts passiert beim Tippen? Dann bist du wahrscheinlich im Browser von WhatsApp o. Ä.
-				Öffne diese Seite in Safari oder Chrome — dort funktionieren Kamera und Galerie. (Im Menü
-				des In-App-Browsers: „In Safari öffnen“ bzw. „Im Browser öffnen“.)
+				Öffne diese Seite in Safari oder Chrome — dort funktioniert die Auswahl. (Im Menü des
+				In-App-Browsers: „In Safari öffnen“ bzw. „Im Browser öffnen“.)
 			</p>
 		{/if}
 

frontend/src/lib/feature-flags.ts

@@ -0,0 +1,36 @@
+import { env } from '$env/dynamic/public';
+
+/**
+ * Build-independent feature switches read from the frontend container's environment.
+ *
+ * Deliberately NOT routed through the backend's `/api/v1/event` payload the way
+ * `comments_enabled` is. That flag describes the EVENT (whether guests may comment at all);
+ * this one describes what the CLIENT can do on the device in front of it. The backend has no
+ * stake in how bytes were captured — an upload from the camera and an upload from the gallery
+ * arrive on the same endpoint, indistinguishable — so putting the switch on the server would
+ * add a schema, a DTO field and a release of the app image to answer a question only the
+ * browser can ask.
+ *
+ * `$env/dynamic/public` is read at RUNTIME by adapter-node, so this is a compose variable and
+ * a restart, not a rebuild.
+ */
+
+/** Interpret a flag the same way `config.rs` does, so operators only learn one convention. */
+function flag(value: string | undefined, fallback: boolean): boolean {
+	if (value === undefined || value.trim() === '') return fallback;
+	return !['false', '0', 'no', 'off'].includes(value.trim().toLowerCase());
+}
+
+/**
+ * Whether the in-app camera is offered (`PUBLIC_CAMERA_ENABLED`, default true).
+ *
+ * Turned off for events where `getUserMedia` misbehaves on the guests' actual phones —
+ * switching between front and back cameras throwing "Kamera konnte nicht gestartet werden",
+ * or video capture failing the permission prompt outright. Those failures are per-device and
+ * cannot be diagnosed mid-event, so the switch removes the broken path rather than leaving
+ * guests to discover it.
+ *
+ * Nothing is lost by disabling it: the gallery picker reaches the same OS camera through
+ * `capture`-less `<input type="file">`, handles video, and is the path most guests use anyway.
+ */
+export const cameraEnabled = flag(env.PUBLIC_CAMERA_ENABLED, true);

frontend/src/lib/upload-queue.ts

@@ -1252,6 +1252,28 @@ async function uploadItem(id: string): Promise<void> {
 						);
 						break;
 					case 'terminal': {
+						// A 400 the APP raised always carries `bad_request` in a JSON envelope
+						// (too large, wrong type, caption too long, NUL byte). Axum's own multipart
+						// rejection does not: it is a PLAIN-TEXT 400 ("Error parsing
+						// `multipart/form-data` request"), so `body` is null here.
+						//
+						// That distinction decides whether a guest keeps their photo. An
+						// unparseable 400 means the request body never arrived intact — a transport
+						// failure, not a verdict on the file — and it is exactly what an iOS in-app
+						// browser (WhatsApp) produces when it truncates an XHR upload. Classified as
+						// terminal, it purged the blob from IndexedDB and offered no retry, so a
+						// webview hiccup destroyed the only copy the guest had.
+						//
+						// Same reasoning the 403 rule below already applies to an unparseable body,
+						// and safe to retry: nothing was parsed, so nothing was stored and no quota
+						// was charged — and `X-Client-Upload-Id` makes a duplicate impossible even
+						// if the server did see it.
+						if (xhr.status === 400 && body?.error !== 'bad_request') {
+							settle(() =>
+								reject(new NetworkError('Übertragung unvollständig — bitte erneut versuchen'))
+							);
+							break;
+						}
 						// A REVERSIBLE lock (event closed / gallery released) is tagged
 						// `uploads_locked` by the backend — keep the blob and park it retryable so
 						// a host reopen resumes it, instead of purging it like a permanent 4xx.