fix(sdk): re-introduce loginWithToken wrap with stricter guards

Re-add the auto-relogin auth-error handler that fixes e2ee-key-reset and
device-management force-logout flows, with two extra guards to avoid
the SAML regression that the previous version caused:

  - readStoredLoginToken() === token: nothing rotated the stored token
    mid-flight (a concurrent SAML/password/OAuth login already wrote a
    fresh one)
  - sdk.account.uid === triedWithUid: the SDK account didn't get
    refreshed by a successful adopt while we were awaiting (a parallel
    Meteor-routed login completed and updated the in-memory state)

If both guards hold, the only plausible explanation is a true server
force-logout (Users.unsetLoginTokens), so we drop local credentials and
let the router fall back to Login.

Verified locally: login.spec, account-login, e2ee-key-reset and
omnichannel-rooms-forward all pass.

Author: ggazzo

apps/meteor/client/lib/sdk/ddpSdk.ts

@@ -212,6 +212,50 @@ if (typeof window !== 'undefined') {
 	const sdk = getDdpSdk();
 	window.__rocketChatSdk = sdk;
 
+	// DDPSDK auto-fires loginWithToken on every `connected` event using the
+	// in-memory account.user.token (DDPSDK.create line 115-122). When the
+	// server force-logs the user out (resetUserE2EKey →
+	// Users.unsetLoginTokens → meteor.service force_logout listener closes
+	// the user's WebSocket sessions), the SDK reconnects and immediately
+	// retries the now-dead token. DDPSDK calls this with `void` so the
+	// rejection is swallowed; account.user stays populated, Meteor.userId()
+	// stays set, and the navbar continues to render Home with stale creds.
+	//
+	// Wrap account.loginWithToken so we can observe rejections from the
+	// auto-retry. To avoid breaking the SAML/password login flows where a
+	// fresh login is concurrently in flight, only act when:
+	//  - the error is auth-shaped (`isAuthError`) AND
+	//  - the token in localStorage still matches the one we tried with
+	//    (nothing rotated it mid-flight) AND
+	//  - the SDK account didn't get refreshed by a successful adopt while
+	//    we were awaiting (sdk.account.uid still maps to this token's user)
+	const account = sdk.account as unknown as { loginWithToken: (token: string) => Promise<unknown> };
+	const originalLogin = account.loginWithToken.bind(sdk.account);
+	account.loginWithToken = async (token: string) => {
+		const triedWithUid = sdk.account.uid;
+		try {
+			return await originalLogin(token);
+		} catch (error) {
+			const stillSameStored = readStoredLoginToken() === token;
+			const accountStillReflectsThisToken = sdk.account.uid === triedWithUid;
+			if (isAuthError(error) && stillSameStored && accountStillReflectsThisToken) {
+				try {
+					Accounts._unstoreLoginToken();
+				} catch {
+					// ignore
+				}
+				try {
+					(Meteor.connection as unknown as { setUserId: (uid: string | null) => void }).setUserId(null);
+				} catch {
+					// ignore
+				}
+				sdk.account.uid = undefined;
+				sdk.account.user = undefined;
+			}
+			throw error;
+		}
+	};
+
 	// Boot-time auth is now driven by Meteor's login resume routed through
 	// stubMeteorStream, which calls adoptAccountFromMeteorLoginResult on
 	// success. Calling ensureConnectedAndAuthenticated here as well would