feat(moderation): let a host remove a guest's photo or comment from the UI

`DELETE /host/upload/{id}` and `DELETE /host/comment/{id}` were complete on the
backend — transactional, SSE-broadcasting, audit-logged — and had zero frontend
callers. The feed context sheet offered "Löschen" only when
`target.user_id === myUserId`, so the only lever a host actually had against an
unwanted photo was banning the uploader.

That is both disproportionate and ineffective. A ban doesn't retract what was
already posted, and it makes things strictly worse for comments: the ban check
runs BEFORE the ownership check on the guest delete route, so banning an abusive
author leaves their comment on screen and permanently undeletable by them. With
no host affordance, nobody could remove it at all.

- feed: hosts/admins get "Beitrag entfernen" on other people's posts, routed to
  the host endpoint (the guest route 403s anything the caller doesn't own) with
  moderation-specific confirm copy. Own-post "Löschen" is unchanged.
- lightbox: same for comments, via /host/comment/{id}.
- Ban semantics are deliberately untouched (USER_JOURNEYS §10 — banned users keep
  read access and cannot write). The deadlock is broken by giving the host a way
  in, not by loosening the ban.

Live role (this had to come first). `getRole()` decodes the JWT claim, but the
token is never reissued — the backend slides the session row forward and treats
the DB row as authoritative. The claim is therefore frozen for the token's
lifetime: up to 30 days. A guest promoted at the party saw no Host-Dashboard and
no moderation actions until they signed out and back in, even though
`/me/context` had been returning their real role on every page load and 4 of its
6 call sites dropped the field on the floor.

Add `role-store.ts`: seeded from the claim so there's no flash of the wrong nav,
then corrected by every `/me/context` response. Point the ad-hoc `getRole()`
callers at it (account, upload, host, admin, and the new feed gate). The host and
admin dashboards now derive `myRole` reactively, so a demotion disables their
controls immediately instead of at next login.

Tests: 04-host/moderation-ui drives the real UI — host removes a guest photo and
it's gone from /feed server-side; a plain guest is offered nothing on someone
else's post (the mirror that keeps the first test honest); a promoted guest gains
the dashboard on reload while their token still carries `role: guest`; and a host
removes the comment of an already-banned guest, asserting first that the author's
own delete 403s so the deadlock is real.

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

frontend/src/lib/role-store.ts

@@ -0,0 +1,34 @@
+import { derived, writable } from 'svelte/store';
+import { getRole } from './auth';
+
+export type Role = 'guest' | 'host' | 'admin';
+
+/**
+ * The viewer's LIVE role.
+ *
+ * The JWT is never reissued — the backend slides the session row forward instead and
+ * deliberately ignores the token's own role claim (`auth/middleware.rs`: "the live user row
+ * is authoritative"). So `getRole()`, which decodes the claim, is frozen for the lifetime of
+ * the token: up to 30 days for a guest. A guest promoted to host saw no Host-Dashboard until
+ * they signed out and back in, even though `/me/context` had already told the client their
+ * real role on the very next page load — it was fetched and the `role` field dropped on the
+ * floor in 4 of its 6 call sites.
+ *
+ * This store is seeded from the claim (so there is no flash of the wrong nav on boot) and
+ * corrected by every `/me/context` response via `setRole`. Read this instead of calling
+ * `getRole()` ad hoc.
+ */
+export const role = writable<Role | null>(getRole());
+
+/** True for host and admin — the "can moderate" predicate used across the UI. */
+export const isStaff = derived(role, ($role) => $role === 'host' || $role === 'admin');
+
+/** Apply the authoritative role from a `/me/context` response. */
+export function setRole(next: Role | null): void {
+	role.set(next);
+}
+
+/** Re-seed from the token, e.g. straight after a login/join that minted a new one. */
+export function syncRoleFromToken(): void {
+	role.set(getRole());
+}