When the old client closes after a Sentry.init() re-initialization, the registered 'close' handler calls setPendingDeepLinkListener(undefined), wiping the new client's listener — silently disabling cold-start late-arrival attribution for any subsequent navigation. The deeplinkIntegration explicitly guards against this pattern (subscription?.remove() before re-subscribing), but the navigation integration does not.

The new deep-link hand-off tests in reactnavigation.test.ts reset the module-level state in pendingDeepLink.ts (pending, listener, seqCounter) by calling clearPendingDeepLink() as the final statement of each test rather than in beforeEach/afterEach. The beforeEach hook (around line 121) clears Jest mocks and Sentry scopes but does not reset the pending deep-link module. In the normal success path this is harmless because consumePendingDeepLink always nulls pending on consumption, so each test self-cleans before its assertions. However, if an expect(...) throws before consumption completes, the trailing clearPendingDeepLink() is skipped (only the 'drops stale' test uses try/finally). A leaked, still-fresh pending value can then bleed into a later test — notably 'does not attach when no deep link is pending', which relies on the slot being empty — turning one genuine failure into confusing downstream failures. Consider moving clearPendingDeepLink() into beforeEach (alongside the existing scope clears) so cleanup is guaranteed regardless of test outcome. This is a test-hygiene improvement, not a production defect.