test(upload): prove the stored bytes are the guest's bytes, not just that a 201 came back

v0.18.3 through v0.18.6 were one failure in four disguises: the browser handing
the queue something that was not the file. An empty body first (WebKit stores a
picked `File` as a reference to an OS file iOS then deletes), and once the bytes
were copied, the risk of a SHORT one — that copy is a multi-second chunked loop
for a video, and the same purge can land partway through it.

Every check that missed them shared one shortcut: asserting the upload was
ACCEPTED. A truncated file is accepted. It passes the magic-byte sniff, the size
cap and the decode budget, is stored, gets a preview, appears in the gallery —
and is still not the guest's video. Acceptance was never the question.

So this drives the real composer through the real file chooser, then fetches the
stored original back and compares its SHA-256 to the file on disk. It also names
the two copy paths, because they are different code and only one of them can
produce a short blob: at or below 4 MB a single `arrayBuffer()`, above it the
chunked loop. A run with no file over 4 MB says so rather than reporting a pass
it did not earn.

Replaces the two throwaway scripts these hotfixes were verified with. Reports
which entries the upload sheet offers, so a run also records whether
PUBLIC_CAMERA_ENABLED was in effect.

Verified against v0.18.6: 32 KB single-read and 14.8 MB chunked, both
byte-identical.

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

.env.example

@@ -231,6 +231,21 @@ COMMENTS_ENABLED=true
 # Prefer a bigger disk if you can: ~45 GB holds a 9.7 GB library WITH the keepsake.
 KEEPSAKE_ENABLED=true
 
+# ── In-app camera ─────────────────────────────────────────────────────────────
+# Whether the upload sheet offers "Kamera — Jetzt aufnehmen" alongside "Galerie".
+# Read at RUNTIME by the frontend container, so changing it is this line plus
+# `docker compose up -d frontend` — no rebuild.
+#
+# Set to false when the in-app camera misbehaves on the guests' actual phones: switching
+# between front and back throwing "Kamera konnte nicht gestartet werden", or video capture
+# failing its permission prompt. Those failures are per-device and cannot be diagnosed
+# mid-event, so this removes the broken path instead of letting guests find it.
+#
+# Nothing is lost by turning it off. The gallery picker opens the phone's own file chooser,
+# which reaches the camera app on both iOS and Android and handles video — it is the path
+# most guests use anyway. The onboarding text and the upload sheet adjust themselves.
+PUBLIC_CAMERA_ENABLED=true
+
 # ── Logging ───────────────────────────────────────────────────────────────────
 # SET THIS IN PRODUCTION. Without it the app falls back to
 # `eventsnap_backend=debug,tower_http=debug` (see main.rs), and with TraceLayer that is a

docker-compose.yml

@@ -226,6 +226,14 @@ services:
       # produces `https://` here and collapses the Caddyfile's site block below, so the stack
       # comes up with no TLS and no site and the only symptom is a browser error.
       ORIGIN: "https://${DOMAIN:?set DOMAIN in .env}"
+      # In-app camera switch, read at RUNTIME by adapter-node — so flipping it is this line
+      # plus `docker compose up -d frontend`, not a rebuild. Set it to "false" when
+      # `getUserMedia` misbehaves on the guests' phones (front/back switching throwing
+      # "Kamera konnte nicht gestartet werden", video capture failing its permission prompt).
+      # Guests then upload through the gallery picker, which still reaches the phone's own
+      # camera app and handles video. Lives on the FRONTEND service, not `app`: the backend
+      # cannot tell a camera upload from a gallery upload and has no stake in the choice.
+      PUBLIC_CAMERA_ENABLED: "${PUBLIC_CAMERA_ENABLED:-true}"
       # V8 sizes its old-space heap from the cgroup limit, but lands on ~101% of it (measured:
       # heap_size_limit 259 MB inside a 256M container). So the JS heap ceiling sits ABOVE the
       # container's entire budget — before base RSS (~60-90 MB), the C++ heap, or SSR response

e2e/docker-compose.sim.yml

@@ -82,6 +82,8 @@ services:
       COMPRESSION_WORKER_CONCURRENCY: '2'
       # Production disables comments for this event (docker-compose.yml, product decision).
       COMMENTS_ENABLED: 'false'
+      # Mirrors the deployed setting so the harness can audit against the real gate.
+      KEEPSAKE_ENABLED: ${SIM_KEEPSAKE:-true}
       # The ONE deviation from production: enables /admin/__truncate so the harness can
       # reset between runs. Never set on the real box.
       EVENTSNAP_TEST_MODE: '1'
@@ -102,7 +104,7 @@ services:
 
   frontend:
     # Shipped release image; `git diff v0.17.6 HEAD -- frontend/` is empty.
-    image: registry.mc02.dev/eventsnap/frontend:v0.17.6
+    image: ${SIM_FE_IMAGE:-registry.mc02.dev/eventsnap/frontend:v0.17.6}
     cpuset: *cpuset
     depends_on:
       - app
@@ -110,6 +112,7 @@ services:
       PORT: '3001'
       HOST: '0.0.0.0'
       ORIGIN: 'http://localhost:3102'
+      PUBLIC_CAMERA_ENABLED: ${SIM_CAMERA:-true}
     deploy:
       resources:
         limits:

e2e/loadtest/acceptance-audit.mjs

@@ -0,0 +1,178 @@
+#!/usr/bin/env node
+/**
+ * Acceptance audit: push EVERY file in the pool through the real upload validator
+ * and report exactly what the server refuses, and why.
+ *
+ * Answers one question — "with these settings, which of my photos would be turned
+ * away?" — and answers it empirically rather than by reasoning about limits. Size
+ * caps are only one of the paths that can refuse a file: the magic-byte allowlist,
+ * the decode budget (12000 px axis / 256 MiB alloc, both code constants), the disk
+ * gate and the per-user quota all reject too, and only the running server knows the
+ * interaction between them.
+ *
+ * Deliberately NOT a load test: no personas, no viewers, no think-time. It measures
+ * admission, so it does not wait for the compression backlog to drain.
+ *
+ *     SIM_UPLOADERS=8 node e2e/loadtest/acceptance-audit.mjs
+ */
+import { readFile, writeFile, mkdir } from 'node:fs/promises';
+import { fileURLToPath } from 'node:url';
+import { dirname, join } from 'node:path';
+import { randomUUID } from 'node:crypto';
+
+const __dirname = dirname(fileURLToPath(import.meta.url));
+const BASE = process.env.SIM_BASE ?? 'http://localhost:3102';
+const API = `${BASE}/api/v1`;
+const POOL = process.env.SIM_POOL_DIR ?? '/tmp/eventsnap-realpool';
+const META = process.env.SIM_POOL_META ?? '/tmp/eventsnap-pool.json';
+const ADMIN_PW = process.env.SIM_ADMIN_PW ?? 'admin-test-pw';
+const CONC = parseInt(process.env.AUDIT_CONC ?? '4', 10);
+// Spread across a few accounts, as a real event does — a single uploader would hit
+// the per-user quota and hourly limit for reasons unrelated to the files themselves.
+const UPLOADERS = parseInt(process.env.SIM_UPLOADERS ?? '8', 10);
+
+const j = async (path, opts = {}) => {
+  const res = await fetch(`${API}${path}`, opts);
+  const text = await res.text();
+  let body;
+  try {
+    body = text ? JSON.parse(text) : undefined;
+  } catch {
+    body = text;
+  }
+  return { status: res.status, body };
+};
+
+async function main() {
+  const meta = JSON.parse(await readFile(META, 'utf8'));
+  console.log(`[pool] ${meta.length} files, ${(meta.reduce((a, f) => a + f.bytes, 0) / 1e9).toFixed(2)} GB`);
+
+  const admin = (
+    await j('/admin/login', {
+      method: 'POST',
+      headers: { 'Content-Type': 'application/json' },
+      body: JSON.stringify({ password: ADMIN_PW }),
+    })
+  ).body.jwt;
+
+  const cfg = (await j('/admin/config', { headers: { Authorization: `Bearer ${admin}` } })).body;
+  const shown = [
+    'max_image_size_mb',
+    'max_video_size_mb',
+    'upload_rate_per_hour',
+    'storage_quota_enabled',
+    'quota_enabled',
+  ];
+  console.log(`[config] ${shown.map((k) => `${k}=${cfg[k]}`).join('  ')}`);
+  const stats = (await j('/admin/stats', { headers: { Authorization: `Bearer ${admin}` } })).body;
+  console.log(
+    `[disk]   ${(stats.disk_free_bytes / 1e9).toFixed(1)} GB free of ${(stats.disk_total_bytes / 1e9).toFixed(1)} GB`
+  );
+
+  const guests = [];
+  for (let i = 0; i < UPLOADERS; i++) {
+    const r = await j('/join', {
+      method: 'POST',
+      headers: { 'Content-Type': 'application/json' },
+      body: JSON.stringify({ display_name: `Audit ${i} ${randomUUID().slice(0, 4)}` }),
+    });
+    guests.push(r.body.jwt);
+  }
+  console.log(`[join]   ${guests.length} uploaders\n`);
+
+  const results = [];
+  let done = 0;
+  const queue = [...meta];
+  const t0 = Date.now();
+
+  const worker = async (slot) => {
+    while (queue.length) {
+      const f = queue.shift();
+      if (!f) break;
+      const jwt = guests[slot % guests.length];
+      let buf;
+      try {
+        buf = await readFile(join(POOL, f.name));
+      } catch (e) {
+        results.push({ ...f, status: -1, msg: `read error: ${e}` });
+        continue;
+      }
+      const form = new FormData();
+      form.append('file', new Blob([buf], { type: f.magic }), f.name);
+      form.append('client_upload_id', randomUUID());
+      let status, body;
+      try {
+        const res = await fetch(`${API}/upload`, {
+          method: 'POST',
+          headers: { Authorization: `Bearer ${jwt}` },
+          body: form,
+        });
+        status = res.status;
+        const t = await res.text();
+        try {
+          body = JSON.parse(t);
+        } catch {
+          body = t;
+        }
+      } catch (e) {
+        status = 0;
+        body = { message: String(e).slice(0, 80) };
+      }
+      results.push({
+        name: f.name,
+        bytes: f.bytes,
+        magic: f.magic,
+        w: f.w,
+        h: f.h,
+        status,
+        code: body?.code ?? body?.error,
+        msg: status >= 400 ? String(body?.message ?? '').slice(0, 110) : undefined,
+      });
+      if (++done % 100 === 0) {
+        const ok = results.filter((r) => r.status === 201).length;
+        console.log(
+          `  ${done}/${meta.length}  accepted ${ok}  refused ${done - ok}  (${((Date.now() - t0) / 1000).toFixed(0)}s)`
+        );
+      }
+    }
+  };
+  await Promise.all(Array.from({ length: CONC }, (_, i) => worker(i)));
+
+  // ── Report ────────────────────────────────────────────────────────────────
+  const ok = results.filter((r) => r.status === 201);
+  const bad = results.filter((r) => r.status !== 201);
+  const byReason = {};
+  for (const r of bad) {
+    const key = `${r.status} ${r.msg ?? r.code ?? '?'}`;
+    (byReason[key] ??= []).push(r);
+  }
+
+  console.log('\n' + '═'.repeat(74));
+  console.log('ACCEPTANCE AUDIT');
+  console.log('═'.repeat(74));
+  console.log(
+    `accepted ${ok.length}/${results.length}  (${(ok.reduce((a, r) => a + r.bytes, 0) / 1e9).toFixed(2)} GB)`
+  );
+  console.log(`refused  ${bad.length}\n`);
+  for (const [reason, rows] of Object.entries(byReason).sort((a, b) => b[1].length - a[1].length)) {
+    const sizes = rows.map((r) => r.bytes / 1024 / 1024);
+    console.log(`  ${rows.length} x ${reason}`);
+    console.log(
+      `      sizes ${Math.min(...sizes).toFixed(1)}–${Math.max(...sizes).toFixed(1)} MB · types ${[...new Set(rows.map((r) => r.magic))].join(', ')}`
+    );
+    console.log(`      e.g. ${rows.slice(0, 3).map((r) => r.name).join(', ')}`);
+  }
+  if (!bad.length) console.log('  ✓ nothing was refused');
+
+  const outDir = join(__dirname, 'results');
+  await mkdir(outDir, { recursive: true });
+  const out = join(outDir, `acceptance-${new Date().toISOString().replace(/[:.]/g, '-')}.json`);
+  await writeFile(out, JSON.stringify({ config: cfg, stats, results }, null, 2));
+  console.log(`\nfull detail → ${out}`);
+  console.log('═'.repeat(74));
+}
+
+main().catch((e) => {
+  console.error('audit failed:', e);
+  process.exit(1);
+});

e2e/loadtest/upload-integrity-check.mjs

@@ -0,0 +1,150 @@
+#!/usr/bin/env node
+/**
+ * Drives a REAL upload through the composer's file picker and proves the bytes survived.
+ *
+ * Written during the v0.18.3–v0.18.6 run of hotfixes, which were all one failure wearing
+ * different masks: the browser handing the queue something that was not the file. First an
+ * empty body (WebKit stores a picked `File` as a reference to an OS file iOS then deletes),
+ * then — once the bytes were copied — the risk of a SHORT one, because that copy is a
+ * multi-second chunked loop for a video and the same purge can land partway through it.
+ *
+ * Every check that missed those bugs shared one shortcut: it asserted the upload was
+ * ACCEPTED. A truncated file is accepted. It passes the magic-byte sniff, the size cap and the
+ * decode budget, is stored, gets a preview, and shows in the gallery — and is still not the
+ * guest's video. So this asserts the only thing that actually settles it: fetch the stored
+ * original back and compare its SHA-256 to the file on disk.
+ *
+ * Two paths matter and they are not the same code:
+ *   * at or below MATERIALISE_CHUNK_BYTES (4 MB) the copy is a single `arrayBuffer()`
+ *   * above it, a chunked loop — the one that can produce a short blob
+ * Pass at least one file of each, or the run proves half of what it claims.
+ *
+ * Requires the sim stack (e2e/docker-compose.sim.yml) on :3102.
+ *
+ *     node e2e/loadtest/upload-integrity-check.mjs photo.jpg big-video.mp4
+ */
+import { chromium, devices } from '@playwright/test';
+import { readFile, stat } from 'node:fs/promises';
+import { createHash } from 'node:crypto';
+import { basename } from 'node:path';
+
+const BASE = process.env.SIM_BASE ?? 'http://localhost:3102';
+const API = `${BASE}/api/v1`;
+/** Mirrors MATERIALISE_CHUNK_BYTES in frontend/src/lib/upload-queue.ts. */
+const CHUNK_BYTES = 4 * 1024 * 1024;
+
+const sha = (buf) => createHash('sha256').update(buf).digest('hex');
+
+const files = process.argv.slice(2);
+if (!files.length) {
+	console.error('usage: upload-integrity-check.mjs <file> [file...]  (include one >4 MB)');
+	process.exit(2);
+}
+
+async function main() {
+	const browser = await chromium.launch();
+	const context = await browser.newContext({ ...devices['Pixel 7'] });
+	// The guide is a modal over the composer; leaving it up means the picker is never reached.
+	await context.addInitScript(() => localStorage.setItem('eventsnap_guide_seen', '1'));
+	const page = await context.newPage();
+	const pageErrors = [];
+	page.on('pageerror', (e) => pageErrors.push(String(e).slice(0, 140)));
+
+	await page.goto(`${BASE}/join`, { waitUntil: 'load' });
+	await page.waitForTimeout(1200);
+	await page.fill('input[type=text]', `Integrity ${Date.now() % 100000}`);
+	await page.locator('button[type=submit]').first().click();
+	await page.waitForTimeout(4500);
+	for (const label of ['Weiter', 'Verstanden', 'Los geht']) {
+		const btn = page.getByRole('button', { name: new RegExp(label, 'i') });
+		if ((await btn.count()) && (await btn.first().isVisible())) {
+			await btn.first().click();
+			await page.waitForTimeout(700);
+			break;
+		}
+	}
+	const token = await page.evaluate(() => localStorage.getItem('eventsnap_jwt'));
+
+	// Report which upload entries the sheet offers, so a run also records whether
+	// PUBLIC_CAMERA_ENABLED was in effect — the composer path differs with it.
+	await page.locator('button[aria-label="Hochladen"]').last().click();
+	await page.waitForTimeout(900);
+	const sheet = await page.locator('body').innerText();
+	console.log(
+		`[sheet] Galerie=${sheet.includes('Foto oder Video wählen')} ` +
+			`Kamera=${sheet.includes('Jetzt aufnehmen')}\n`
+	);
+	// Close it again. The FAB TOGGLES, so leaving the sheet open here makes the loop's first
+	// "open the sheet" click close it instead — and the file chooser then never fires.
+	await page.getByRole('button', { name: /Abbrechen/i }).first().click();
+	await page.waitForTimeout(600);
+
+	const results = [];
+	for (const path of files) {
+		const name = basename(path);
+		const local = await readFile(path);
+		const size = (await stat(path)).size;
+		const caption = `integrity ${name} ${Date.now()}`;
+		const chunked = size > CHUNK_BYTES;
+
+		// Open the sheet fresh for every file — submitting returns to the feed, and the
+		// invariant this relies on is simply that the sheet is CLOSED at the top of each pass.
+		await page.locator('button[aria-label="Hochladen"]').last().click();
+		await page.waitForTimeout(900);
+		const chooser = page.waitForEvent('filechooser');
+		await page.getByText('Foto oder Video wählen').click();
+		(await chooser).setFiles(path);
+		await page.waitForTimeout(2500);
+		await page.locator('textarea').fill(caption);
+		await page.getByRole('button', { name: /^Hochladen$/ }).first().click();
+		// Generous: the queue retries, and a large file on a throttled box takes its time.
+		await page.waitForTimeout(Math.max(9000, (size / 1e6) * 900));
+
+		// Find it server-side. The feed is the guest's own view, so this also proves the photo
+		// is actually visible rather than merely stored.
+		const feed = await fetch(`${API}/feed?limit=50`, {
+			headers: { Authorization: `Bearer ${token}` },
+		}).then((r) => r.json());
+		const row = feed.uploads?.find((u) => u.caption === caption);
+		if (!row) {
+			results.push({ name, size, chunked, ok: false, why: 'never appeared in the feed' });
+			continue;
+		}
+		// The whole point: compare the bytes that came BACK, not the status that went out.
+		const served = Buffer.from(
+			await fetch(`${API}/upload/${row.id}/original`).then((r) => r.arrayBuffer())
+		);
+		const ok = served.length === size && sha(served) === sha(local);
+		results.push({
+			name,
+			size,
+			chunked,
+			ok,
+			why: ok ? '' : `stored ${served.length} of ${size} bytes / hash mismatch`,
+		});
+	}
+
+	await browser.close();
+
+	console.log('═'.repeat(66));
+	console.log('UPLOAD INTEGRITY');
+	console.log('═'.repeat(66));
+	for (const r of results) {
+		console.log(
+			`  ${r.ok ? '✓' : '✗'} ${r.name.padEnd(24)} ${(r.size / 1e6).toFixed(1).padStart(6)} MB  ` +
+				`${r.chunked ? 'chunked copy' : 'single read '}  ${r.why}`
+		);
+	}
+	if (!results.some((r) => r.chunked))
+		console.log('\n  ⚠ no file above 4 MB — the chunked copy path was NOT exercised');
+	if (pageErrors.length) console.log(`\n  page errors: ${pageErrors[0]}`);
+	const failed = results.filter((r) => !r.ok).length;
+	console.log(`\n${failed ? `✗ ${failed} of ${results.length} corrupted` : `✓ all ${results.length} byte-identical`}`);
+	console.log('═'.repeat(66));
+	process.exit(failed ? 1 : 0);
+}
+
+main().catch((e) => {
+	console.error('integrity check failed:', e);
+	process.exit(1);
+});

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',
@@ -41,8 +48,19 @@
 		{
 			kind: 'text',
 			icon: '👆',
-			title: 'Lange tippen für mehr',
+			title: 'Mehr zu einem Foto',
-			body: 'Tippe lange auf ein Bild im Feed, um zusätzliche Aktionen zu öffnen — zum Beispiel das Original anzeigen oder eigene Beiträge löschen.'
+			// Names the VISIBLE control first. Long-press was the only affordance mentioned here,
+			// and it is invisible — a guest has to already know it exists. The three-dot button
+			// is on every card in list view and is what most people will find.
+			//
+			// Both views are named on purpose: the button exists only in the LIST view
+			// (FeedListCard). The grid tiles have no button at all, only `use:longpress`, so a
+			// guest browsing in grid mode would be stranded by a menu-only instruction.
+			//
+			// "anzeigen und speichern", not "herunterladen": the action opens the original in a
+			// new tab (`Content-Disposition: inline`, deliberate — it is the only playable video
+			// source), so the guest saves it from there rather than getting a download.
+			body: 'Tippe oben rechts am Beitrag auf die drei Punkte (⋯), um weitere Aktionen zu öffnen: das Original in voller Auflösung anzeigen und speichern oder eigene Beiträge löschen. In der Kachel-Ansicht tippst du stattdessen lange auf ein Bild.'
 		},
 		{
 			kind: 'theme',
@@ -52,9 +70,18 @@
 		{
 			kind: 'text',
 			icon: '🔑',
-			title: 'Deinen PIN merken!',
+			title: 'Name und PIN merken!',
+			// Recovery needs BOTH the display name and the PIN (`POST /recover` takes
+			// {display_name, pin}), but this step only ever mentioned the PIN — so a guest who
+			// memorised four digits and forgot whether they typed "Anna" or "Anna M." still
+			// could not get back in.
+			//
+			// "solange du auf diesem Gerät angemeldet bleibst" replaces "ist immer … zu finden",
+			// which was false in exactly the case that matters: /account renders the PIN from
+			// local storage and falls back to "PIN nicht gespeichert", so it is NOT there on a
+			// new device — which is the only reason anyone needs it.
 			body:
-				'Du hast beim Registrieren einen 4-stelligen PIN erhalten. Speichere ihn — du brauchst ihn, um dein Konto auf einem anderen Gerät wiederherzustellen. Er ist immer unter „Mein Konto“ zu finden.' +
+				'Beim Registrieren hast du einen 4-stelligen PIN bekommen. Für die Anmeldung auf einem anderen Gerät brauchst du beides: genau den Namen, den du hier eingegeben hast, und diesen PIN. Notiere dir am besten beides — solange du auf diesem Gerät angemeldet bleibst, findest du sie unter „Mein Konto“.' +
 				(hasPrivacyNote ? ' Den Datenschutzhinweis findest du ebenfalls unter „Mein Konto“.' : '')
 		}
 	]);

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) -->
+<!-- Camera (rendered outside sheet so it gets full viewport).
-{#if showCamera}
+     `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
@@ -305,8 +315,14 @@
 			     line of text and is never wrong. It lives here rather than in the root layout
 			     because both layout banners are gated on `$showBottomNav`, which `/upload` turns
 			     off — a banner there would never render on the composer. -->
+			<!-- "diese Seite", not "den Link": the guest is already inside the app when they read
+			     this, so there is no link on screen for "den Link" to refer to. Naming the app
+			     they most likely arrived from, and the menu entry that gets them out, turns a
+			     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? Öffne den Link in Safari oder Chrome.
+				Nichts passiert beim Tippen? Dann bist du wahrscheinlich im Browser von WhatsApp o. Ä.
+				Ö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.test.ts

@@ -1,6 +1,7 @@
 import { describe, it, expect } from 'vitest';
 import {
 	classifyUploadStatus,
+	isIncompleteBody,
 	isReversibleLock,
 	entryToQueueItem,
 	shouldAbortForStall,
@@ -54,6 +55,91 @@ describe('classifyUploadStatus', () => {
  * reopen and the photo resumes) or PURGES it (permanent ban / quota). Getting this wrong either
  * loses a photo the guest expected to survive a reopen, or lets a banned device retry forever.
  */
+/**
+ * Regression guard for the data loss this was written for: an iPhone guest on the live event
+ * got "Error parsing `multipart/form-data` request", the item went terminal, and the ONLY copy
+ * of the photo was purged from IndexedDB with no retry offered.
+ *
+ * The first attempt at the fix keyed on the envelope (`body.error !== 'bad_request'`) and was
+ * inert, because the backend wraps the multipart error in its own `bad_request` envelope. These
+ * 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';
+
+	it('the exact live failure: bad_request envelope carrying the parse error → incomplete', () => {
+		expect(isIncompleteBody(400, { error: 'bad_request', message: parseError, status: 400 })).toBe(
+			true
+		);
+	});
+
+	it('the same error raised mid-file, with the German prefix → incomplete', () => {
+		expect(
+			isIncompleteBody(400, {
+				error: 'bad_request',
+				message: `Datei konnte nicht gelesen werden: ${parseError}`,
+				status: 400
+			})
+		).toBe(true);
+	});
+
+	it('an unparseable body (plain-text rejection, proxy, WAF) → incomplete', () => {
+		expect(isIncompleteBody(400, null)).toBe(true);
+		expect(isIncompleteBody(400, undefined)).toBe(true);
+	});
+
+	it('a real verdict on the file → NOT incomplete, so it still purges', () => {
+		expect(
+			isIncompleteBody(400, { error: 'bad_request', message: 'Datei ist zu groß. Maximum: 500 MB.' })
+		).toBe(false);
+		expect(
+			isIncompleteBody(400, { error: 'bad_request', message: 'Keine Datei hochgeladen.' })
+		).toBe(false);
+		expect(
+			isIncompleteBody(400, { error: 'bad_request', message: 'Dateityp wird nicht unterstützt.' })
+		).toBe(false);
+	});
+
+	it('only applies to 400 — other statuses keep their own rules', () => {
+		expect(isIncompleteBody(413, { error: 'quota_exceeded' })).toBe(false);
+		expect(isIncompleteBody(403, null)).toBe(false);
+		expect(isIncompleteBody(500, null)).toBe(false);
+	});
+});
+
 describe('isReversibleLock', () => {
 	it('an `uploads_locked` code is reversible at any status (event closed / released)', () => {
 		expect(isReversibleLock(403, 'uploads_locked')).toBe(true);

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
@@ -701,6 +709,48 @@ export function classifyUploadStatus(status: number): UploadOutcome {
 	return 'transient';
 }
 
+/**
+ * Within the `terminal` bucket, is this 400 a TRUNCATED REQUEST rather than a verdict on the
+ * file? Keep the blob and retry if so. Pure + exported for the same reason as
+ * `isReversibleLock`: it decides whether a guest keeps their photo.
+ *
+ * Keyed on the MESSAGE, not the envelope. The obvious rule — "an app-raised 400 carries
+ * `bad_request`, so a 400 without it is Axum's plain-text rejection" — does not hold, and was
+ * verified against the running backend rather than reasoned about:
+ *
+ *   stream breaks between parts   → 400 application/json
+ *                                   {"error":"bad_request","message":"Error parsing `multipart/…"}
+ *   stream breaks mid-file        → 400 application/json, same code, message prefixed
+ *                                   "Datei konnte nicht gelesen werden: …"
+ *   no boundary in Content-Type   → 400 text/plain "Invalid `boundary` for `multipart/…"
+ *
+ * Only the third is Axum's own extractor rejection. The first two — the ones a webview or a
+ * dropping mobile link actually produce — never reach it: the handler pulls the fields itself
+ * and wraps `MultipartError` in `AppError::BadRequest` (`upload.rs` field loop and chunk loop),
+ * so they arrive as an ordinary `bad_request` envelope, indistinguishable by code from "file too
+ * large" or "caption too long". An envelope check therefore never fires for the case this
+ * exists to catch. Confirmed live: the log line for a real guest failure and for a synthetic
+ * truncation are byte-identical.
+ *
+ * Retrying is safe: 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.
+ *
+ * The substring is Axum's `MultipartError` Display text and is therefore an UPSTREAM contract
+ * this file does not own — an axum upgrade could reword it and silently re-open the data loss.
+ * The durable fix is a distinct backend code (e.g. `body_incomplete`) that this can prefer once
+ * it exists; the match is kept as the fallback because it needs no app-image release.
+ */
+export function isIncompleteBody(status: number, body: unknown): boolean {
+	if (status !== 400) return false;
+	const envelope = body as { error?: unknown; message?: unknown } | null | undefined;
+	// An unparseable body (proxy, WAF, captive portal) cannot be a considered rejection either.
+	if (!envelope || envelope.error !== 'bad_request') return true;
+	return (
+		typeof envelope.message === 'string' &&
+		envelope.message.includes('Error parsing `multipart/form-data` request')
+	);
+}
+
 /**
  * Within the `terminal` bucket, decide whether a 4xx is a REVERSIBLE lock (keep the blob,
  * park retryable for a host reopen) rather than a permanent rejection (purge the blob).
@@ -839,7 +889,49 @@ export async function releaseResolvedParks(state: {
 
 /** Outcome of an `addToQueue` call, so the caller can tell the user when a file was NOT
  *  actually queued (deduped, or the queue is full of un-evictable in-flight items). */
-export type EnqueueResult = 'queued' | 'duplicate' | 'full';
+export type EnqueueResult = 'queued' | 'duplicate' | 'full' | 'unreadable';
+
+/** 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> {
+	let out: Blob;
+	if (file.size <= MATERIALISE_CHUNK_BYTES) {
+		out = new Blob([await file.arrayBuffer()], { type: file.type });
+	} else {
+		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()]));
+		}
+		out = new Blob(parts, { type: file.type });
+	}
+	// Verify the copy. The purge this whole function exists to defeat can also land PARTWAY
+	// THROUGH the loop above: a 500 MB video is many seconds of reading, and once the OS file
+	// is gone the remaining slices read as nothing. `new Blob` is happy to build a short blob
+	// out of them, and short is far worse than absent — it uploads, the server stores it, and
+	// the guest gets a truncated video that looks like it worked. A read that returns fewer
+	// bytes than the file claims is never legitimate, so refuse it here, while the guest is
+	// still holding the phone and can pick the file again.
+	if (out.size !== file.size) {
+		throw new UnreadableBlobError(
+			'Diese Datei konnte nicht vollständig gelesen werden — bitte wähle sie noch einmal aus.'
+		);
+	}
+	return out;
+}
 
 export async function addToQueue(
 	file: File,
@@ -887,6 +979,31 @@ 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.
+	// A file the browser cannot fully read is not a queueable item. Returning a result rather
+	// than throwing keeps the composer's per-file loop intact: one bad photo out of five must
+	// not abandon the other four, which is what an exception here would do.
+	let blob: Blob;
+	try {
+		blob = await materialise(file);
+	} catch {
+		return 'unreadable';
+	}
 	const entry: QueueEntry = {
 		id,
 		userId,
@@ -897,7 +1014,7 @@ export async function addToQueue(
 		caption,
 		hashtags,
 		status: 'pending',
-		blob: file
+		blob
 	};
 	await storePut(entry);
 
@@ -1070,6 +1187,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
@@ -1120,7 +1242,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);
 
@@ -1252,6 +1393,15 @@ async function uploadItem(id: string): Promise<void> {
 						);
 						break;
 					case 'terminal': {
+						// A truncated body is a transport failure, not a verdict on the file, so it
+						// must not purge the blob. See `isIncompleteBody` for why the envelope alone
+						// cannot decide this.
+						if (isIncompleteBody(xhr.status, body)) {
+							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.
@@ -1429,6 +1579,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.

frontend/src/routes/join/+page.svelte

@@ -309,8 +309,15 @@
 				{/if}
 			{:else}
 				<!-- Normal join form -->
+				<!-- The article is HARDCODED to match this event's name ("Hochzeit von …"), so the
+				     lead-in and the <h1> below read as one sentence: "Willkommen bei der Hochzeit
+				     von …". That couples this string to EVENT_NAME's grammatical gender — it is
+				     wrong for "Willkommen bei der Sommerfest". Deliberate for a single event; if
+				     this app is reused, either make the article configurable alongside EVENT_NAME
+				     or drop back to an article-free lead-in ("Herzlich willkommen!"), which works
+				     with any name. The fallback below must keep agreeing with whatever is chosen. -->
 				<p class="mb-1 text-center text-sm font-medium text-gray-500 dark:text-gray-400">
-					Willkommen bei
+					Willkommen bei der
 				</p>
 				{#if eventName}
 					<h1
@@ -320,8 +327,10 @@
 						{eventName}
 					</h1>
 				{:else}
+					<!-- "Feier", not "dem Event": the lead-in above now carries the article, so the
+					     old fallback would render "Willkommen bei der dem Event". -->
 					<h1 class="mb-3 text-center text-3xl font-semibold text-gray-900 dark:text-gray-100">
-						dem Event
+						Feier
 					</h1>
 				{/if}
 				<p class="mb-6 text-center text-gray-600 dark:text-gray-400">

frontend/src/routes/upload/+page.svelte

@@ -163,6 +163,16 @@
 				}
 				const result = await addToQueue(sf.file, caption, hashtagsString);
 				if (result === 'full') full++;
+				// The browser could not read this file's bytes (iOS purges the OS file behind a
+				// picked photo). Named per file rather than counted like `full`: the guest has to
+				// find and re-pick this specific one, so a bare number would not be actionable.
+				if (result === 'unreadable') {
+					toast(
+						`„${sf.file.name}“ konnte nicht gelesen werden. Bitte wähle das Foto noch einmal aus.`,
+						'error',
+						8000
+					);
+				}
 			}
 			// Don't let a full queue silently swallow photos the user thinks were queued.
 			if (full > 0) {
@@ -308,6 +318,18 @@
 				rows="4"
 				class="input resize-none text-sm"
 			></textarea>
+			<!-- Persistent helper, NOT a second placeholder line. Two reasons: a `placeholder`
+			     attribute may not contain line breaks (Safari collapses them outright), and a
+			     placeholder disappears the moment the guest starts typing — which is exactly when
+			     they need to read what to write. This stays visible while they type.
+			     The hashtag is written plain on purpose: `#fotoaufgabe3` would be a DIFFERENT tag
+			     from `#fotoaufgabe`, so twelve tasks would produce twelve unfilterable tags. The
+			     number belongs in the prose, the hashtag stays one word. -->
+			<p class="mt-1.5 text-xs leading-snug text-gray-500 dark:text-gray-400">
+				<span class="font-semibold text-gray-600 dark:text-gray-300">Fotoaufgabe?</span> Schreib
+				die Aufgabe dazu — die Nummer steht unten rechts auf dem Kärtchen — und setze den Hashtag
+				#fotoaufgabe.
+			</p>
 			<div class="mt-1 text-xs text-gray-500 text-right dark:text-gray-400">
 				{caption.length} / {MAX_CAPTION_LENGTH}
 			</div>