fix: close the nine ways an unattended event loses photos or dies

Every one of these was found in the pre-event audit, verified against source, and
survives to production on the current main. Grouped by what actually goes wrong.

PHOTOS DISAPPEAR

* compression.rs no longer soft-deletes on a failed derivative. The guest got a
  201, watched the card appear, then watched it vanish — the row left v_feed,
  find_visible_media and BOTH keepsakes, while its bytes sat on disk for 14 days
  waiting for a cleanup nothing announced. No screen anywhere lists compression
  failures, so recovery meant hand-written SQL that also had to re-add the
  refunded quota. Now it does exactly what the ENOSPC arm beside it already did
  and documented as correct: keep the row, serve the original, retry on the next
  boot (bounded by derivative_attempts). `upload-deleted` is no longer emitted;
  `upload-processed` is, so the card re-renders instead of sitting on a
  placeholder.

* A 413 is now a reversible lock, so the blob survives. The quota moves — free
  disk falls, uploader count rises — so a guest goes over it having done nothing,
  and treating that as permanent meant a 400 MB video was pushed across cellular
  in full and THEN deleted from IndexedDB. Gone on both sides, and unrecoverable
  for an in-app camera capture that exists nowhere else.

* quota_limit_bytes gained a floor and a stable divisor. The ceiling used to
  decrease monotonically all evening; it now settles at max(uploaders,
  estimated_guest_count) — a config key that was seeded, validated in the admin
  whitelist, and read by no code at all. The floor is clamped to what the disk
  can actually back, so a full volume still yields zero rather than handing out
  an allowance it cannot honour.

* Because that floor gives up the aggregate guarantee the formula used to imply,
  uploads now check a hard 10 GB reserve first, independent of every quota
  toggle. postgres_data, media_data and exports_data share one filesystem: the
  end state was not a degraded feature, it was Postgres unable to write WAL.

THE ARCHIVE DISAPPEARS

* prune_superseded_archives runs only after the new generation lands. It ran
  before the preflight, reasoning the old archive was already unreachable — true
  of reachability, false of recoverability. An epoch is a value that can be
  rolled back; deleted bytes cannot. Any failed rebuild left the event with NO
  keepsake at all.

* The export preflight reserves the same 10 GB. `free < needed` authorised an
  export sized at exactly free, which ran for half an hour and landed the box at
  zero with the keepsake still unfinished.

THE APP DIES

* The feed reconcile re-reads the id set after its awaits instead of reusing one
  captured up to three round-trips earlier. The new-upload SSE handler prepends
  during exactly that window, so the row was both already present and absent from
  the stale set — prepended twice, and a duplicate key in a keyed {#each} throws
  in production, not just dev. The SSE handler and loadMore now dedupe too.

* Added routes/+error.svelte. Without it any uncaught error fell through to
  SvelteKit's unstyled English 500 with no reload control — inside a chromeless
  standalone PWA with no URL bar, for the rest of the evening.

THE OPERATOR IS LOCKED OUT

* admin_login verifies the password BEFORE charging the rate bucket, and a
  correct password is never throttled. The old order made this a denial of
  service against its own operator: every guest shares one NAT IP, the check ran
  first, so five requests a minute from any phone in the room kept the bucket
  full — and the escape hatch needed the admin session being blocked. A generous
  separate ceiling still bounds bcrypt CPU.

THE PROJECTOR DIES

* The preload budget is now strictly inside the dwell. At the 3s option the 4s
  budget could never land a commit on a slow uplink, so the wall froze on one
  photo while the queue drained silently behind it.

* The wake lock retries every 30s while visible, and the page says so on screen
  when the browser has no wake lock API. visibilitychange was the only retry
  trigger and a kiosk never changes visibility, so one refusal — iOS in Low Power
  Mode, say — was permanent.

* Caddy: /api/v1/upload/*/display joins the cacheable carve-out. The backend set
  max-age=300 on it and the blanket no-store silently replaced it, so a projector
  re-fetched a full-size JPEG per slide, ~2-4 GB over an evening on the uplink
  the guests are uploading over.

Also removes Upload::soft_delete, now unreferenced and an unscoped footgun next
to soft_delete_in_event.

Verified: 146/146 backend tests against a live Postgres, clippy clean, 51/51
vitest, svelte-check 0 errors, eslint clean, vite build, caddy validate, compose
YAML parse.

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

frontend/src/lib/upload-queue.ts

@@ -535,13 +535,24 @@ export function classifyUploadStatus(status: number): UploadOutcome {
  *
  * Reversible when:
  *  - the backend tagged it `uploads_locked` (event closed / gallery released — a host can reopen), OR
+ *  - it's `quota_exceeded` (413). The per-user ceiling is `free_disk * tolerance / uploaders`,
+ *    which MOVES: the numerator falls and the denominator rises all evening, so a guest who was
+ *    comfortably under it at 20:00 is over it at 22:00 through nobody's action, and a host
+ *    deleting content or the hourly reclaim can put them back under it just as passively. It is
+ *    the textbook reversible lock, and treating it as permanent meant a 400 MB video was pushed
+ *    across cellular in full and THEN deleted from IndexedDB — gone on both sides, unrecoverable
+ *    without re-picking from the camera roll (impossible for an in-app camera capture). OR
  *  - it's ANY 403 we can't positively identify as a permanent ban (`forbidden`). An unparseable
  *    403 body (proxy/WAF/captive portal) must NOT purge the blob — losing a photo is the worst
  *    outcome, and 403 is the reversible-lock status here.
- * A `forbidden` 403 (banned) and every non-403 4xx (e.g. 413 quota) are permanent → purge.
+ * A `forbidden` 403 (banned) and every other 4xx (too large, wrong type) are permanent → purge.
  */
 export function isReversibleLock(status: number, errorCode: unknown): boolean {
-	return errorCode === 'uploads_locked' || (status === 403 && errorCode !== 'forbidden');
+	return (
+		errorCode === 'uploads_locked' ||
+		errorCode === 'quota_exceeded' ||
+		(status === 403 && errorCode !== 'forbidden')
+	);
 }
 
 /**
@@ -982,7 +993,9 @@ async function uploadItem(id: string): Promise<void> {
 							settle(() => reject(new LockedError(body?.message || 'Event ist geschlossen.')));
 							break;
 						}
-						// Any other 4xx the server will keep rejecting (banned / quota).
+						// Any other 4xx the server will keep rejecting (banned, too large, wrong
+						// type). Quota is NOT here any more — it moves with free disk and the
+						// uploader count, so it is a reversible lock handled above.
 						let msg = body?.message || 'Upload nicht möglich.';
 						if (!body?.message && xhr.status === 413) msg = 'Speicher-Limit erreicht.';
 						settle(() => reject(new TerminalError(msg)));
@@ -1028,9 +1041,12 @@ async function uploadItem(id: string): Promise<void> {
 			throw e; // Propagate to processQueue for scheduling
 		}
 		if (e instanceof LockedError) {
-			// Event closed / gallery released, but a host can reopen — KEEP the blob and park
-			// the item as retryable so it survives until reopen. The `event-opened` SSE
-			// (bindSse) auto-resumes it; a manual "Erneut" also works. Never purge here.
+			// A condition that can lift without the guest doing anything: the event is closed or
+			// the gallery released (a host can reopen), or the storage quota is currently
+			// exceeded (it moves with free disk and the uploader count, and a host takedown or
+			// the hourly media reclaim puts them back under it). KEEP the blob and park the item
+			// as retryable so it survives until then. `event-opened` and the `feed-delta`
+			// reconnect both auto-resume it; a manual "Erneut" also works. Never purge here.
 			const exhausted = chargeAttempt(entry);
 			entry.status = 'error';
 			entry.error = withRetryHint(e.message, exhausted);