fix(sdk): reset Accounts._lastLoginTokenWhenPolled on SDK disconnect

Belt-and-suspenders for the EE force-logout path. The existing recovery
mechanisms (useForceLogout via stream message; _reconnectStopper via
fire('reset') calling makeClientLoggedOut on auth failure) BOTH clear
_lastLoginTokenWhenPolled when they run. But in microservices the
notify-user/<uid>/force_logout stream traverses
rocketchat-main → broker → ddp-streamer → WS while the close fires
directly on ddp-streamer — so the stream message can be lost mid-flight,
leaving useForceLogout out of the picture. _reconnectStopper still
covers that case by retrying with the stale token and falling into
makeClientLoggedOut, but only if a previous successful login registered
the stopper.

Wire a direct sdk.connection.on('disconnected') listener that nulls
_lastLoginTokenWhenPolled. The next _pollStoredLoginToken call (from
the 3s timer or a test's loginByUserState) now always compares against
null and fires a login if a token is stored, regardless of whether the
two earlier paths ran.

In normal blip-and-recover network drops the SDK auto-relogin succeeds
and the next poll re-sends a (no-op for the server) login resume — extra
roundtrip but no user-visible effect.

Verified locally with e2ee-passphrase-management :76/:87 and
e2ee-key-reset (force-logout) all green.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: ggazzo

apps/meteor/client/meteor/overrides/stubMeteorStream.ts

@@ -1,3 +1,4 @@
+import { Accounts } from 'meteor/accounts-base';
 import { DDPCommon } from 'meteor/ddp-common';
 import { Meteor } from 'meteor/meteor';
 import { Tracker } from 'meteor/tracker';
@@ -247,3 +248,21 @@ sdk.connection.on('connected', () => {
 		console.warn('[stubMeteorStream] reset on SDK reconnect failed', err);
 	}
 });
+
+// Belt-and-suspenders: when the underlying SDK socket disconnects, also reset
+// `Accounts._lastLoginTokenWhenPolled` so the next `_pollStoredLoginToken`
+// (whether triggered by the 3s polling timer or an external poke like a test's
+// `loginByUserState`) is forced to compare against `null` and fire a fresh
+// login if the stored token still exists. This covers the gap where neither
+// `useForceLogout` (stream message lost in the broker race) nor
+// `_reconnectStopper`'s `makeClientLoggedOut` ran — without this, a stored
+// token equal to the cached `_lastLoginTokenWhenPolled` short-circuits the
+// poller and the user sits with stale credentials until the next genuine
+// token rotation.
+sdk.connection.on('disconnected', () => {
+	try {
+		(Accounts as unknown as { _lastLoginTokenWhenPolled?: string | null })._lastLoginTokenWhenPolled = null;
+	} catch {
+		// ignore — we just want the poller to wake up next time
+	}
+});