Drop push tokens wherever a user is signed out

Status: unreleased. This page describes work on branch mo/clear_push_tokens_on_logout (PR #421), not yet shipped to customers.

The one-sentence version

When Dentolize forces a staff member's session to end — a password reset, a permission change, an admin locking the account, disabling a whole clinic — the server now also erases that user's stored mobile push-notification tokens, so a phone that no longer has a valid session stops receiving push notifications for it.

Why this exists

A phone registers a push-notification token the moment someone logs into the Dentolize clinic app on it. From then on, the server uses that token to ping the phone about new appointments, invoices, tasks, chat messages, and more — entirely independent of whether the app still has a live session open.

Lots of actions in Dentolize end a user's session on purpose: a manager resets someone's password, an owner edits a staff member's permission group, a user turns on two-factor authentication, an admin disables a clinic's account after non-payment. All of these correctly kill the session. None of them, until now, told the phone's push token to go away too. The token had only ever been cleaned up by the one flow that adds it — logging in — and by the literal "Logout" button. Every other session-ending action left the token sitting in the database, so a device that had just been signed out of by someone else kept quietly buzzing with clinic notifications.

What changed

Four resolver files gained one line each (or a small addition to an existing data object): wherever the code already tears down a user's session(s) as a side effect of some other action, it now also sets that user's pushNotifications list to empty. No new mutation, no new UI, no new permission — this is a targeted correctness fix to existing mutations:

• disableCompany (admin/owner disabling a clinic)
• adminDisableTwoFactor (support forcibly turning off 2FA)
• updateAuthDetails (self-service password change)
• resetPassword (forgot-password flow)
• confirm2FAToken (turning 2FA on)
• disable2FA (self-service turning 2FA off)
• editGroup (changing what a permission group can do)
• deleteGroup (deleting a permission group)
• editUser (editing any staff member's profile)

See How push tokens are registered and cleared for the mechanics, and The mutations this PR changes for a mutation-by-mutation breakdown with exact code references.

What did not change

• The mobile app is unchanged — no new screen, button, or setting. This is entirely server-side plumbing.
• The Logout button already had its own (narrower) push-token cleanup; that is untouched.
• logoutOutAllUsers ("Logout All Users", reachable from Account → Security) already cleared push tokens for the whole company before this PR — it was the prior art this PR generalizes to the other session-killing mutations.
• This PR does not add any new session (UserSession row) cleanup where it was missing before — for example disableCompany still only invalidates the Redis-cached session, it does not delete the UserSession database rows. That gap is unrelated to push tokens and out of scope here.