fix(audit): restore broken upload pipeline + role-based E2E audit fixes

A comprehensive role-based E2E audit (guest/host/admin, across browser
sessions) surfaced one critical and several smaller issues; this addresses
them and hardens the tests that missed them.

Critical
- The client upload pipeline was fully broken: the IndexedDB v1->v2 upgrade
  opened a *new* transaction inside the upgrade callback, which throws during
  a version-change transaction and aborted the whole upgrade, leaving the
  queue object store uncreated -- so no UI upload ever fired. Reuse the
  version-change transaction the callback provides, and bump the DB to v3 with
  a contains() guard so installs already corrupted by the shipped bug
  self-heal on next load. Re-enabled the previously-fixme'd UI upload E2E test.

High / Medium
- Event lock is uploads-only again: likes, comments and browsing stay open
  while the event is locked (USER_JOURNEYS 9.3 / FEATURES) -- it was wrongly
  freezing social interaction. Updated the event-lock spec accordingly.
- get_original now excludes soft-deleted and ban-hidden uploads, and direct
  /media/originals/** serving is blocked, so a hidden user's originals can no
  longer be pulled by UUID (all originals go through the checked alias).
- The upload handler reads the file field with an early-abort size cap chosen
  from the declared content-type, instead of buffering the entire body before
  the size check.

Low
- unban_user mirrors the ban role guard (a host can no longer unban a
  host/admin banned by an admin).
- reset_user_pin's UPDATE is event-scoped.
- Admin login returns and stores a real identity (user_id + display name)
  instead of a blank session.
- The host user list no longer renders target-actions (ban/promote/demote/PIN)
  on the caller's own row, where the backend always rejected them.
- /diashow gains a client-side auth guard like the other protected routes.
- The join page shows the event name via a new public GET /api/v1/event.

Verified: backend cargo build clean, frontend svelte-check 0 errors, full
Playwright E2E suite 144 passed / 1 skipped.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

e2e/specs/02-upload/gallery-path.spec.ts

@@ -38,15 +38,14 @@ test.describe('Upload — gallery path', () => {
     await expect.poll(() => db.countUploadsForUser(h.userId), { timeout: 10_000 }).toBe(2);
   });
 
-  test.fixme('UI flow: FAB → UploadSheet → /upload → submit drives a real XHR upload', async ({ page, guest, signIn, db }) => {
-    // The full UI flow (BottomNav FAB → UploadSheet → /upload page → handleSubmit →
-    // upload-queue.ts XHR) does not currently complete within the test window in
-    // Playwright. The XHR doesn't appear in backend logs. Suspected cause: the
-    // queue worker fires after the page navigates from /upload to /feed via
-    // SvelteKit's goto(), but the blob/IDB chain may not survive the unmount/
-    // remount cycle in Playwright's headless Chromium. Needs deeper
-    // investigation; tracked as a fixme for now. API-driven tests above cover
-    // the data contract.
+  test('UI flow: FAB → UploadSheet → /upload → submit drives a real XHR upload', async ({ page, guest, signIn, db }) => {
+    // Previously fixme'd: the UI queue never fired a POST. Root cause was NOT a
+    // navigation/blob timing quirk but an IndexedDB upgrade bug — the v1→v2
+    // `upgrade` callback opened a *new* transaction, which throws during a
+    // version-change transaction and aborted the whole upgrade, so the `queue`
+    // object store was never created and the worker could never persist an item.
+    // Fixed in upload-queue.ts by reusing the callback's version-change
+    // transaction. This test guards against regressing that.
     const h = await guest('UploaderUI');
     await signIn(page, h);
     const feed = new FeedPage(page);

e2e/specs/04-host/event-lock.spec.ts

@@ -34,10 +34,11 @@ test.describe('Host — event lock', () => {
     // and flip fixme to test once it lands.
   });
 
-  // Regression for the review: likes/comments used to ignore uploads_locked_at,
-  // so social writes still landed on a closed event. They now share the upload
-  // handler's lock guard.
-  test('a closed event rejects likes and comments', async ({ api, host, guest }) => {
+  // Locking is uploads-only: likes, comments and browsing stay open on a closed
+  // event (USER_JOURNEYS §9.3, FEATURES capability matrix). Only new uploads are
+  // rejected. (An earlier revision froze social interaction too; that contradicted
+  // the documented behavior and was reverted.)
+  test('a closed event still allows likes and comments, but blocks new uploads', async ({ api, host, guest }) => {
     const BASE = process.env.E2E_FRONTEND_URL ?? 'http://localhost:3101';
     const g = await guest('SocialLocked');
 
@@ -55,17 +56,26 @@ test.describe('Host — event lock', () => {
 
     await api.closeEvent(host.jwt);
 
+    // Likes stay open on a locked event.
     const likeRes = await fetch(`${BASE}/api/v1/upload/${id}/like`, {
       method: 'POST',
       headers: { Authorization: `Bearer ${g.jwt}` },
     });
-    expect(likeRes.status).toBe(403);
+    expect(likeRes.status).toBe(204);
 
+    // Comments stay open on a locked event.
     const commentRes = await fetch(`${BASE}/api/v1/upload/${id}/comments`, {
       method: 'POST',
       headers: { Authorization: `Bearer ${g.jwt}`, 'Content-Type': 'application/json' },
-      body: JSON.stringify({ body: 'sollte blockiert sein' }),
+      body: JSON.stringify({ body: 'darf durchgehen' }),
     });
-    expect(commentRes.status).toBe(403);
+    expect(commentRes.status).toBe(201);
+
+    // New uploads, however, are rejected while locked.
+    const blockedUpload = await uploadRaw(g.jwt, readFileSync(sample), {
+      filename: 'y.jpg',
+      contentType: 'image/jpeg',
+    });
+    expect(blockedUpload.status).toBe(403);
   });
 });