fix(user-flow): persona-audit fixes — ban replay, locked-upload data loss, host UX, admin session

Follows the perf + security + user-flow work with a role/persona audit (guest, host,
admin, projector) and fixes across three review rounds. Highlights:

HIGH
- Ban now replays on reconnect. A ban isn't a soft-delete, and the `user-hidden` SSE has
  no replay, so a client that missed it (esp. the unattended diashow) kept cycling a
  banned user's slides. New `uploads_hidden_at` (migration 013) + `hidden_user_ids` in
  /feed/delta; feed + diashow evict those users. Applied even on a truncated delta.

MEDIUM
- Locked-upload data loss: a photo staged offline during a lock/release was purged as a
  terminal 4xx and lost when the host reopened. New reversible `uploads_locked` error code;
  the queue keeps the blob and auto-resumes on the `event-opened` SSE.
- Reopen after release now warns (ConfirmSheet) that it revokes the published keepsake.
- Host "forgotten-PIN" badge updates live (`pin-reset-requested` was broadcast but never
  in KNOWN_EVENTS / subscribed); host page also refetches on `pin-reset` so a two-host
  race can't hand out a conflicting PIN.
- Ban modal copy fixed (read-only ban, not "session ended"); Degradieren/Sperren/Entsperren
  hidden on peer-host rows for non-admins (they always 403'd).
- Host dashboard shows live keepsake generation progress / ready state + link to /export.
- Admin JWT moved to sessionStorage (§11.1) to bound exposure on shared devices.

Export generation guard (H1 from the prior round, hardened): per-(event,type) `release_seq`
(migration 012) with seq-guarded claim/finalize/mark_failed/update_progress, per-generation
temp/final paths, download follows `file_path`, prune only strictly-older generations.

LOW: diashow coalesces upload-processed (avoids self-rate-limit); event-closed reconciles
galleryReleased; /recover gains a forgot-PIN request + drops a stale cached PIN on 401;
delta `>=` tie-break + 429 retry; misc copy/labels.

Adds e2e: ban-replay, upload-lock-code, and rewrites export-reopen-rerelease with a
data-completeness test. Reconciles USER_JOURNEYS §9/§11.

Verified: cargo build clean, 40 unit tests, svelte-check 0 errors, 33 frontend unit
tests, 155 e2e passing on chromium-desktop.

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

docs/USER_JOURNEYS.md

@@ -132,15 +132,20 @@ the Host can clean up later).
    - **Sperren** opens a confirmation modal. Banning **always hides** the user's existing
      uploads (a banned user's content is "gone" everywhere) — there is no opt-out. Submitting
      calls `POST /host/users/{id}/ban` (no body).
-   - **Entsperren** lifts the ban.
-   - **Host** promotes a guest to host.
-   - **Degradieren** — visible on Host rows. A Host can demote *other* Hosts back to
-     guest (planned). The button is hidden on the Host's own row to prevent self-lockout;
-     only an Admin can demote themselves out of moderation. Admins see Degradieren on
-     every Host row.
-   - **PIN zurücksetzen** (planned) — generates a new PIN and shows it once in a modal.
-     See journey §4. Hosts see this on Guest rows only; Admins see it on Guest + Host
-     rows.
+   - **Entsperren** lifts the ban. Same authority boundary as ban (below): a plain Host may
+     only unban Guests; only an Admin may unban a Host.
+   - **Host** promotes a guest to host (Hosts and Admins may do this).
+   - **Degradieren** — demote a Host back to guest. **Only an Admin may change a Host's
+     role.** A plain Host may *not* demote a peer Host: doing so would let them then ban or
+     PIN-reset (→ `/recover` account-takeover) that ex-peer, since those guards key off the
+     target's *current* role. So the backend rejects it (403) and the button is hidden for
+     non-admin Hosts. Nobody may change their own role (self-lockout / self-escalation guard),
+     and Admins are un-demotable and un-bannable by anyone. (This tightens an earlier
+     "Hosts may demote other Hosts" design — see the F1 security fix.)
+   - **Sperren / PIN zurücksetzen** — a plain Host may act on Guests only; an Admin may act on
+     Guests + Hosts; nobody may act on an Admin. The buttons are hidden where they'd 403.
+     PIN reset generates a new PIN, shows it once in a modal, and revokes the target's
+     existing sessions (forcing re-auth with the new PIN). See journey §4.
 6. **Deleting content** — Host can delete any upload or comment via the moderation routes
    (`DELETE /host/upload/{id}`, `DELETE /host/comment/{id}`). On mobile this is also
    reachable by long-pressing the content (planned, see §15).