fix(review-2): medium/low + docs — config validation, hygiene, doc sync

- compression_concurrency wired to boot config (state.rs) and removed as a
  dead admin control.
- patch_config gains per-key integer/range validation so numerically-valid-but-
  nonsensical values (-1/NaN/3.5) are rejected instead of silently reverting to
  default at read time.
- clearAuth now also clears the display name (shared-device residual).
- e2e/Caddyfile.test mirrors prod security headers + the SSE encode-exclusion so
  the test stack is representative and can catch header regressions.
- .gitignore: ignore root-level Playwright artifacts (test-results/, report).
- docs: USER_JOURNEYS §10 and SECURITY-BACKLOG updated to match the implemented
  read-only-ban behavior and the export-path fix.

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

docs/SECURITY-BACKLOG.md

@@ -64,8 +64,11 @@ decompression-bomb cap (`image::Limits` 12000×12000 / 256 MiB) lives in
   (not just the exact dev sentinel) and enforces `len ≥ 32` unconditionally in prod.
 - **Unspoofable client IP in the rate limiter** — `client_ip` now takes the right-most
   `X-Forwarded-For` entry (the hop Caddy appends), so a client-supplied left-most value is ignored.
-- **Live role/ban re-check** — the auth extractor re-reads the user row and trusts the DB role and
-  `is_banned` flag rather than the JWT claim, revoking demoted/banned sessions immediately.
+- **Live role/ban re-check** — the auth extractor re-reads the user row and trusts the DB `role`
+  and `is_banned` flag rather than the JWT claim, so a demote/ban takes effect immediately (no
+  30-day token window). Bans are enforced on write handlers + the host/admin extractors, preserving
+  the documented read-only access for banned guests (USER_JOURNEYS §10); demoted hosts lose host
+  powers at once.
 - **Container healthchecks** — `app` and `frontend` now have healthchecks and Caddy waits on
   `service_healthy`.
 - **Event-scoped `ban_user`** — the ban UPDATE is now scoped by `event_id` like its siblings.

docs/USER_JOURNEYS.md

@@ -147,12 +147,18 @@ the Host can clean up later).
 
 ## 10. Banned-guest experience
 
-1. The banned user's next authenticated request returns HTTP 403 with a clear message
-   ("Du bist gesperrt.").
-2. They can still browse the read-only feed (and download the export once it's released).
-3. They cannot upload, like, or comment.
-4. If `hide_uploads` was set on the ban, their existing uploads are filtered out of the
-   feed for everyone (the `v_feed` view already enforces this).
+1. The ban takes effect immediately on the banned user's existing session — the auth
+   layer re-reads the live `is_banned` flag on every request rather than trusting the
+   JWT, so there's no 30-day token-lifetime window.
+2. Their next authenticated *write* request returns HTTP 403 with a clear message
+   ("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).
+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.
 
 ## 11. Admin — instance configuration