Optimizing login-token invalidation by emitting dedicated events

[Pratheek555]

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