fix(storage): cascade DeleteUser to all user-keyed tables

[lakhansamani]

Closes #747

Problem

StorageProvider.DeleteUser cascaded to sessions only. Every other row keyed on the user id survived, so a hard delete left orphans in six tables.

The federated-identity orphan is a permanent SSO lockout, not just untidiness: jitProvisionFederatedUser resolves a returning principal through the (org_id, issuer, subject) row, finds it points at a user id that no longer exists, and fails closed on every subsequent login. Re-provisioning cannot recover it either — the triple is unique, so AddFederatedIdentity collides. Deleting the row by hand was the only fix.

Couchbase was worse: its DeleteUser deleted no children at all, not even sessions.

Fix

schemas.UserOwnedCollections is the single source of truth — sessions, federated identities, org memberships, authenticators, passkeys, session tokens, MFA sessions. All six backends cascade over it, so a new user-keyed table is covered everywhere by adding one line.

• SQL keeps a parallel userOwnedModels (GORM deletes by model, not table name), all inside the existing transaction.
• The five non-transactional backends delete children first and the user row last. They previously deleted the user first; with a partial failure that ordering manufactures exactly the orphan this issue is about, with no retry path. Children-first leaves the user intact and a retried delete completes the job.
• Admin _delete_user also purges the user's FGA tuples (internal/service/fga.go). Tuples live outside StorageProvider, so the storage cascade cannot reach them.

Two deliberate calls on the FGA purge

Synchronous, not asyncutil.Go. It stays best-effort and logged as the issue proposed — a tuple-store failure does not fail a delete that already happened — but it runs inline. A deleted user must not be observably still holding grants, and async made the regression test racy.

It pages the whole tuple store and matches client-side. OpenFGA's Read API rejects a user-only filter — it requires at least an object type (pkg/server/commands/read.go: "the object type field is required") — and we do not know which types a user appears under. A ponytail: comment names the ceiling and the upgrade path (enumerate the model's types via ReadModel, one filtered Read per type) if the store ever grows big enough to matter.

Not changed

Soft deletes do not cascade. DeactivateAccount and revoke-access only stamp RevokedTimestamp and never call DeleteUser — the account is meant to come back. This holds by construction, since the cascade lives entirely inside DeleteUser.

accountHasState (oauth_account_state.go) is left as-is. It exists because this cascade was incomplete, but relaxing a security bound is a separate decision — refusing is recoverable, deleting is not.

Tests

• Cross-backend testDeleteUserCascade in the storage suite: create a user with a membership, TOTP authenticator, passkey, federated identity, session token and MFA session; delete; assert every row is gone. Includes the lockout regression — the same (org, issuer, subject) triple must be free for re-provisioning.
• Static parity check (TestDeleteUserCascadeIsUniform), mirroring TestNotFoundContractIsUniform: AST-asserts each backend's DeleteUser cascades over the shared list. This is the check that would have caught the Couchbase gap — CI runs SQLite only, so a cascade covering six tables on SQL and none on Couchbase stays green forever.
• SQL: userOwnedModels ↔ UserOwnedCollections table-name alignment (via gorm.Statement.Parse, not hand-guessed snake-casing), plus an atomic-rollback test proving a failed cascade step does not leave the user row deleted on its own.
• Integration: end-to-end _delete_user with an FGA grant, asserting the tuple is gone.

Both halves were confirmed to actually catch the bug — dropping FederatedIdentity from the list fails the lockout regression; removing the purge call fails the tuple assertion.

Verification

go build, go vet, make test and make lint all clean.

Per AGENTS.md, the storage suite was run live against all six backends, not SQLite alone:

Backend	Result
SQLite	pass
ArangoDB	pass
MongoDB	pass
DynamoDB	pass
ScyllaDB	pass
Couchbase	pass