For Stakeholders

Why this matters

Dentolize handles staff accounts with access to patient medical and financial records across potentially many clinic branches. Several existing controls exist specifically to cut off a staff member's access quickly: resetting a compromised password, disabling two-factor after a lockout, editing or removing someone's permissions, or suspending a clinic outright.

Before this PR, all of those controls fully worked for their primary purpose — the person really was signed out and could not act in the app. What they missed was a secondary channel: the person's phone kept a live push-notification subscription, so it kept silently receiving Dentolize push notifications (appointment info, invoice alerts, chat messages, task assignments) even though the account had just been locked down. That's a data-exposure risk on a device that, by definition, the clinic no longer trusts with access — e.g. a terminated employee's personal phone.

This PR closes that gap without adding any new surface area: no new mutation, no new permission, no new UI. It's nine one-line-or-so additions to mutations that already existed and already killed sessions.

Risk profile

• Low implementation risk. Every change follows an established pattern already proven in logoutOutAllUsers ({ set: [] } on the same field, in the same transaction as existing session teardown). No schema change, no new dependency, no client-side change.
• Low regression risk. The affected mutations already invalidate the user's access when they run; this only adds one more field to the same database writes. Worst case if something were wrong: a user's push notifications stop working until their next login — an inconvenience, not a data or availability incident.
• Residual gap, explicitly out of scope: disableCompany still does not delete the affected UserSession database rows (it only invalidates the Redis-cached session) — those rows become inert but linger. That's a separate, smaller bookkeeping issue, not a security hole, and is not addressed by this PR.

Impact if not shipped

Low urgency but nonzero: the exposure window is "between when an admin ends someone's session for security reasons and when that person's device happens to have its old token expire or get overwritten" — which in the worst case (a device that's never logged into again) is indefinite. No known incident triggered this PR per the description; it reads as proactive hardening rather than incident response.