Optimizing login-token invalidation by emitting dedicated events

Description:

Login tokin invalidation currently goes through the generic 'watch.users' updates (via services.resume.loginTokens), instead of a dedicated event/channel for session changes.

Because of this, services that only care about login token changes must subscribe to broad user update traffic and filter every watch.users event. This creates unnecessary fan out and avoidable processing overhead.

Steps to reproduce:

1. Trigger flows that remove login tokens (e.g. enable 2FA, logout other clients, logout).
2. Observe emitted internal events.
3. Confirm login token changes are broadcast through watch.users user diffs.

Expected behavior:

• Login token/session invalidation should be emitted through a dedicated internal event (session-focused).
• Consumers interested only in token/session updates should subscribe to that targeted event.
• watch.users should remain focused on generic user profile/state updates.

Actual behavior:

• Login token changes are sent through watch.users.
• Consumers that only need session/token updates are forced to listen to all user change events and filter manually.

Additional context

Related TODO comments are present in multiple places indicating this optimization opportunity

Start by tracing services.resume.loginTokens and the watch.users event path, including the locations with the related TODO comments. Review the flows for 2FA, logout of other clients, and logout, then identify the consumers that depend on these updates. Done means session or login-token invalidation has a targeted internal event while watch.users remains for generic user changes.