fix(auth): bind the role store to the identity, not to the tab

The role store I added in the moderation work is a module-level singleton seeded
ONCE at import. `goto()` is a client-side navigation, so leaving and re-joining in
the same tab re-imports no module and re-runs no onMount — the previous user's
role simply stayed resident. Nothing reset it: not join, recover, admin login,
"Event verlassen", `clearAuth`, nor the api.ts 401 auto-clear.

So a host who left, followed by a guest joining on the same phone, left that guest
with `isStaff === true` and a "🚫 Beitrag entfernen" action on other people's
photos. The backend 403s the delete, so this was a false affordance rather than a
privilege escalation — but `/feed` never fetched `/me/context`, so unlike every
other route it never self-corrected either. It survived until a hard reload.

The mirror case was equally broken and easier to overlook: a guest who recovered
into a host account got NO host affordances.

`clearAuth` already had a hook registry for exactly this shape of problem, with a
comment explaining it exists to avoid circular imports. Add the missing mirror,
`onSetAuth`, fired by both `setAuth` and `setAdminAuth` after the new token is
resident, and have the role store register on both sides: clear to null on
logout, re-seed from the new token on login. That also gives
`syncRoleFromToken` — dead code with zero callers since I introduced it — its
intended purpose.

Seeding from the claim fixes the reported bug, but the claim is frozen for the
token's 30-day life, so a promotion or demotion still wouldn't reach the feed.
`/feed` now calls the existing `refreshEventState()` on mount, which fetches
`/me/context` and applies both the authoritative role and the lock/release state
in one request. The feed is the one route gating a destructive action on the role,
so it should not be the only route running on a stale claim.

Tests: 04-host/role-identity-reset drives the real flows. The first asserts the
host DOES see the action before asserting the newcomer does not — a negative
assertion alone would pass against a build that shipped no moderation at all. The
second covers the mirror, promoting a guest server-side while their resident token
still claims `role: guest`, so a fix that only cleared the role would fail it.

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

frontend/src/routes/feed/+page.svelte

@@ -18,6 +18,7 @@
 	import { pullToRefresh } from '$lib/actions/pull-to-refresh';
 	import { vibrate } from '$lib/haptics';
 	import { filterUploads } from '$lib/feed-filter';
+	import { refreshEventState } from '$lib/event-state-store';
 	import type { FeedUpload, FeedResponse, HashtagCount, DeltaResponse } from '$lib/types';
 
 	let uploads = $state<FeedUpload[]>([]);
@@ -233,6 +234,15 @@
 			}
 		}
 
+		// Pull the authoritative role/event state. The root layout does this on a full page
+		// load, but arriving here from /join or /recover is a client-side navigation, so its
+		// onMount never re-runs — and the feed is the one route that gates a destructive
+		// action (host "Beitrag entfernen") on the role. Without this the feed would run on
+		// whatever the JWT claim said, which is frozen for the token's 30-day lifetime and so
+		// misses a promotion or demotion entirely. Cheap, and it refreshes the lock/release
+		// state in the same request.
+		void refreshEventState();
+
 		await Promise.all([loadFeed(), loadHashtags()]);
 		connectSse();