Logged-in users can still reach the Register page

## What happens When you're already signed in, navigating to the **Register** page (`/register` or whatever the create-account route is) still shows the full "Create your account" form. The header even shows your avatar and username at the same time, so the page is in a contradictory state: the chrome says you're logged in, the body says "sign up to get started." See screenshot — `alexis` is logged in (visible in top-right), notification bell + "New Organization" button are present, yet the page body is the signup form with First name / Last name / Username / Email fields. ## Expected If the visitor is already authenticated, the Register (and Login) pages should not be reachable. Standard pattern: - Redirect to `/` (home) or to wherever the user normally lands after login. - Optionally flash a one-line toast: "You're already signed in." A logged-in user should never see the "Create your account" form. Same applies to the **Login** page — should redirect home if already authenticated. ## Reproduction 1. Sign in. 2. Navigate manually to the register route (type the URL or click an old bookmark). 3. Observe: registration form renders even though the header shows you're logged in. ## Likely root cause (technical) The register / login routes are missing the "redirect-if-authenticated" guard. Two common patterns to check: 1. **Page-level**: in `app/(auth)/register/page.tsx` (or equivalent), do an auth check at the top — if a session exists, `redirect('/')` (Next.js server-side redirect). 2. **Middleware-level**: `middleware.ts` already handles "redirect-if-NOT-authenticated" for protected routes; mirror it with a "redirect-if-authenticated" rule for `/register`, `/login`, and any other guest-only routes. The pattern should be applied to **all guest-only auth surfaces** (register, login, password recovery, etc.) so it's a single audit pass rather than a one-off fix. ## Edge case The Authentik recovery flow (`auth-dev.gathrings.com/if/flow/...`) lives outside the Next.js app and has its own session model — that's a separate concern (cf. Fider #70). Scope this bug to the in-app routes. ## Impact - Confusing UX: the page tells signed-in users to create an account. - If they fill in the form and submit, the backend will likely reject (existing email / username) — but the user has been led down a dead-end path. - Could trick users into thinking they need a second account. ## Found by Manual testing