Cancel Account Deletion

Call off a scheduled deletion and return the restored account.

Deliberately does NOT depend on get_current_user. That dependency is what locks a pending-deletion account out (403 on every route), so a cancel endpoint behind it could only ever be called by someone who has nothing to cancel. app/dependencies.py anticipates exactly this: "they only see the cancel-deletion endpoint via a special path".

So this resolves the caller the way POST /auth/sync does — decode the session JWT, trust sub — which also scopes the escape hatch to a real browser session:

• An API key is not a JWT, so _decode_token rejects it.
• An OAuth access token IS an HS256 JWT signed with the same secret by default (oauth_signing_secret falls back to supabase_jwt_secret), but _decode_token verifies audience="authenticated" and OAuth tokens carry the resource audience instead, so it is rejected too. That is load-bearing: dropping the audience check in some future refactor would open this route to every MCP connector token.
• sub is read only after the signature verifies, and is the sole identity used, so a caller cannot act on anyone but themselves.

NOTE: no route-level rate-limit dependency, and that is not an oversight. Every limiter in app/rate_limit.py is built on tier_rate_limit, whose _enforce takes user: CurrentUser = Depends(get_current_user). FastAPI resolves route dependencies before the handler body, so attaching one here reintroduces the 403 through the back door and makes this endpoint permanently unreachable for the only people who need it. The cap is applied inside the body instead, via enforce_shared_bucket.