Deleting a user from an Organization does not fully remove the global user record (orphaned data + compounds with #905)

### Describe the Bug

Removing a user from an Organization via the dashboard ("Benutzer verwalten" → remove/delete) only deletes the corresponding rows in userOrgs and userOrgRoles. The global user table row — and its dependent rows in tables like twoFactorBackupCodes (and, where present, session/olms) — are not removed. The user therefore silently disappears from the org member list (looking like a full deletion) while remaining permanently in the global user table.

### Environment

- OS Type & Version: Debian 12
- Pangolin Version: v1.21.1
- Edition (Community or Enterprise): Enterprise (licensed)
- Gerbil Version: 1.4.3
- Traefik Version: v3.7
- Newt Version: 1.15.0
- Client Version: Olm — version not yet confirmed, will update
- Database: default SQLite

### To Reproduce

Core bug:

Invite a user to an Organization, have them accept (creates a full user row + userOrgs/userOrgRoles entries).
In the Organization's "Benutzer verwalten" view, delete/remove that user.
Confirm they no longer appear in the org member list (userOrgs/userOrgRoles rows are gone).
Check Server Admin → "Alle Benutzer", or query the user table directly: the row is still present, along with orphaned twoFactorBackupCodes rows.

Compounding scenario with #905:

Follow steps 1–3 above for user with email X.
Immediately try to invite X again to the same or another org, before realizing the old user row still exists.
The new invite gets created but the flow does not complete cleanly — a stale userInvites row is left behind, blocking any further invite attempt to X with a misleading "user already exists" error, and with no UI path to cancel/resend (same symptom as #905, but triggered here by the incomplete user deletion rather than an SMTP failure).

### AI Disclosure

This report was diagnosed and written with the assistance of an AI assistant (Claude, Anthropic). The AI was used to help query and interpret the SQLite schema, correlate the two failure modes, and draft this report text. All commands were reviewed and executed manually by the reporter against a backed-up copy of the database before being applied to the live instance; no AI system had direct access to the production database or credentials.

### Expected Behavior

Deleting a user from their only/last Organization should either:

fully delete the global user row and all dependent rows (cascade), or
clearly surface that the user still exists globally (e.g., still listed in Server Admin) rather than silently vanishing from the org view while remaining elsewhere.

Additionally, the dashboard should provide a way to cancel/purge a stuck userInvites entry without direct DB access.

Start at the Organization “Benutzer verwalten” removal flow and trace the userOrgs and userOrgRoles deletion through the global user table and dependent tables such as twoFactorBackupCodes, session, and olms. Check the Server Admin “Alle Benutzer” view and the invite flow involving userInvites, including the behavior described in #905. Done means deletion is consistent and repeat invitations do not leave a blocking stale invite or misleading error.

Written by the indexing model from the issue text.