Cannot deactivate account — generic "try again" toast hides 403 FORBIDDEN

## What happens Clicking **Deactivate Account** in Settings → Danger Zone fails. The dialog shows the generic error **"Could not deactivate your account. Please try again."** — but retrying produces the same result. No information about *why* it failed is surfaced to the user. ## Backend response (DevTools) `PATCH` to the deactivate endpoint on `dev.gathrings.com` returns **HTTP 403** with: ```json { "ok": false, "code": "FORBIDDEN", "message": "You cannot deactivate this account." } ``` The backend has a clear answer ("FORBIDDEN — You cannot deactivate this account"); the frontend just doesn't show it. ## Two problems stacked ### Problem 1 — Frontend: generic toast hides the real reason The deactivation handler shows a hardcoded fallback message regardless of the backend's `code`/`message`. The user has no path to self-diagnose. This is the same UX pattern flagged in **Fider #71** (LAST_OWNER promotion error) and **Fider #94** (cancelled-event RSVP error). Fix: surface the backend's `message` (or translate the `code` via i18n) in the toast / dialog error area. Examples: - `LAST_OWNER` → "You're the only Owner of one or more organizations. Transfer ownership before deactivating." - `OUTSTANDING_OBLIGATION` (or similar) → "You're hosting upcoming events. Cancel them or transfer hosting before deactivating." - Generic `FORBIDDEN` fallback only when no recognised code is returned. ### Problem 2 — Backend: why is `FORBIDDEN` correct here? The response code (`FORBIDDEN`) and generic message suggest a guard fired but isn't telling us which one. Likely candidates: 1. The user (alexis) is the **last/sole Owner** of at least one organization. Backend correctly refuses deactivation because the org would be orphaned — same pattern as Fider #71. If this is the case, the error code should be specific (`LAST_OWNER_OF_ORG` or similar) so the frontend can route the user to a transfer flow. 2. The user has **upcoming events they're hosting** and the backend treats that as blocking. Same shape — needs a specific code. 3. Some **stale guard** prevents self-deactivation entirely (would be a real bug — admins shouldn't be the only deactivator of a user's own account). Decide which guard fired (audit logs / structured logging on the deactivate path) and either: - Replace the generic `FORBIDDEN` with a **specific error code** per guard so the frontend can render a useful message AND offer a corrective action (e.g. "Transfer your organizations first" with a link). - If the user is genuinely allowed to deactivate, fix the guard. ## Reproduction 1. Sign in to dev as a user who is the sole Owner of at least one organization (alexis fits — see Fider #71 screenshot). 2. Settings → Edit Profile → scroll to **Danger Zone** → click **Deactivate Account**. 3. Confirm the dialog. 4. Observe: red error "Could not deactivate your account. Please try again." 5. DevTools → Network: PATCH to deactivate returns 403 with `code: "FORBIDDEN"`, `message: "You cannot deactivate this account."`. ## Impact - Users hit a dead end — no way to know what to fix. - Looks like the feature is broken ("try again" with no change in behaviour is a textbook bad-UX pattern). - For sole-owner accounts: combined with **Fider #71** (can't promote anyone to Owner) the user is *doubly* stuck — they can't add a co-owner *and* can't deactivate. Account is permanently undeletable. ## Related - **Fider #71** — `LAST_OWNER` blocks promotion to Owner. Likely shares the underlying logic with this guard. - **Fider #94** — draft event RSVP returns generic `event is cancelled` message; same class of frontend-toast-hides-real-reason bug. - **Fider #79** — group manage page shows generic permission error; another instance of the same anti-pattern. A single sweep of the BFF / handler error-mapping layer to surface backend `code`/`message` would fix all four at once. ## Found by Manual testing