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);