fix(sdk): revert to full fire('reset') on SDK reconnect

Surgical onReconnect-only call broke message-actions, report-message,
and e2ee-encryption-decryption — those tests fire methods exactly when
the SDK socket churns from a force-logout cycle, and without the full
reset's _callOnReconnectAndSendAppropriateOutstandingMethods step the
methods stay marked sentMessage=true forever. The bridge's async catch
already absorbs the "method result but no methods outstanding" warnings
that the resent blocks generate, so the noise is harmless.

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

Author: ggazzo

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

@@ -1,4 +1,3 @@
-import { DDP } from 'meteor/ddp';
 import { DDPCommon } from 'meteor/ddp-common';
 import { Meteor } from 'meteor/meteor';
 import { Tracker } from 'meteor/tracker';
@@ -216,18 +215,22 @@ queueMicrotask(() => {
 // When the underlying SDK socket reconnects (e.g. after a server-side
 // ws.terminate from force-logout in microservices), Meteor's connection sees
 // no transport event because the stub keeps reporting 'connected'. As a
-// result, Meteor's normal reconnect machinery never fires the per-call
-// _reconnectStopper that callLoginMethod registers — the one that retries
-// login with the latest stored token and calls makeClientLoggedOut on
-// failure (accounts_client.js:292). The user is left with stale credentials.
+// result, Meteor's normal reconnect machinery — `_streamHandlers.onReset` →
+// `_callOnReconnectAndSendAppropriateOutstandingMethods` → DDP.onReconnect
+// callbacks → the per-call `_reconnectStopper` that retries login with the
+// latest stored token (and calls `makeClientLoggedOut` on failure) — never
+// fires. The user is left with stale credentials.
 //
-// Invoke the DDP.onReconnect callbacks directly on every subsequent SDK
-// 'connected' event so accounts-base's stopper runs. Skip the full
-// _streamHandlers.onReset path: re-sending the outstanding method blocks
-// confuses Meteor (those methods already completed on the previous SDK
-// session and re-feeding them through the bridge yields "method result but
-// no methods outstanding"); and DDPSDK already re-subscribes its own
-// publications on reconnect so we don't need _resendSubscriptions either.
+// Fire `reset` on every subsequent SDK 'connected' event so accounts-base's
+// onReconnect callback retries login with whatever's currently in
+// localStorage AND so methods that were sent but not yet completed get
+// resent on the new session (skipping this part wedges tests that fire a
+// method right when the SDK socket churns: message-actions / report-message
+// / e2ee-encryption-decryption all timed out without it). The first connect
+// is handled by the queueMicrotask above; skip it here. The "method result
+// but no methods outstanding" warnings that the resent blocks generate are
+// caught and suppressed by the bridge's async catch in
+// ddpSdkCollectionBridge.
 const sdk = getDdpSdk();
 let firstConnectHandled = false;
 sdk.connection.on('connected', () => {
@@ -236,13 +239,8 @@ sdk.connection.on('connected', () => {
 		return;
 	}
 	try {
-		const hook = (DDP as unknown as { _reconnectHook?: { each(cb: (callback: (conn: unknown) => unknown) => boolean): void } })
-			._reconnectHook;
-		hook?.each((callback) => {
-			callback(Meteor.connection);
-			return true;
-		});
+		fire('reset');
 	} catch (err) {
-		console.warn('[stubMeteorStream] onReconnect callbacks on SDK reconnect failed', err);
+		console.warn('[stubMeteorStream] reset on SDK reconnect failed', err);
 	}
 });