fix(user-flow): close offline-queue, export, session, ban & realtime gaps

Comprehensive user-flow review across guest/host/admin roles, then fixes with
e2e regression guards. Highlights:

- Offline upload queue auto-resumes on reconnect: network errors keep items
  pending (not error), 4xx are terminal (no infinite retry), quota exhaustion
  returns a distinct 413; queue cap + dedup.
- Export lifecycle: release atomically locks uploads; reopen invalidates and
  re-release regenerates the keepsake; workers claim their job atomically so a
  reopen->re-release can't corrupt the ZIP; startup re-spawns interrupted
  exports.
- Sessions slide on activity (no 30-day cliff); JWT expiry deferred to the
  revocable session row; sign-out-everywhere + revoke-on-PIN-reset.
- Ban always hides content (v_feed / find_visible_media / export filter
  is_banned) but stays a read-only ban per USER_JOURNEYS §10 — sessions are
  not revoked, read access + keepsake download preserved.
- Realtime: server-clock SSE delta cursor; event-closed/opened drive the UI
  live; feed_delta rate-limited; like returns {liked, like_count} to fix
  multi-device drift; lightbox live comments; diashow delta backfill.
- Forgotten-PIN in-app request flow; simultaneous same-name join returns 409;
  quota increment is transactional; operator floor.

Adds e2e/specs/10-flow-review/ (offline resume, export integrity, deterministic
anti-race guard) and updates existing specs for the new contracts.

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

docs/USER_JOURNEYS.md

@@ -129,9 +129,9 @@ the Host can clean up later).
    viewer). Progress is visible in the Admin dashboard's Export tab; SSE
    `export-progress` keeps it live; `export-available` notifies all guests when ready.
 5. **Nutzerverwaltung** — search users; per-user controls:
-   - **Sperren** opens a confirmation modal with a checkbox "Uploads aus der Galerie
-     ausblenden" — Host chooses whether to hide the user's existing uploads or leave them
-     visible. Submitting calls `POST /host/users/{id}/ban` with `hide_uploads`.
+   - **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
@@ -154,11 +154,15 @@ the Host can clean up later).
    ("Du bist gesperrt."). Ban enforcement lives on the write handlers and the
    host/admin extractors, not the base auth extractor.
 3. They can still browse the read-only feed (and download the export once it's released).
+   Their sessions are **not** revoked — this is a read-only ban, not a logout. Their own
+   live SSE stream is dropped by the `is_banned` revalidation (no live pushes), but plain
+   feed reads still work.
 4. They cannot upload, like, or comment; a banned host also loses all host/admin
    actions (including unbanning themselves).
-5. If `hide_uploads` was set on the ban, their existing uploads are filtered out of the
-   feed for everyone (`v_feed` enforces this), and a live `user-hidden` SSE event evicts
-   their cards from every open feed + the diashow without a reload.
+5. Banning **always hides**: the user's existing uploads are filtered out of the feed for
+   everyone (`v_feed`, `find_visible_media`, and the export query all enforce
+   `is_banned = FALSE`), and a live `user-hidden` SSE event evicts their cards from every
+   open feed + the diashow without a reload.
 
 ## 11. Admin — instance configuration