Use PUSH instead of REPLACE for 2FA Download codes navigation on web

[MobileMage]

Explanation of Change

On web, the Download codes button on the 2FA recovery-codes step navigated to the Verify step with forceReplace: true (a REPLACE action). On macOS Chrome, the native "Save As" dialog blurs the tab and delays the popstate event past React Navigation's 100 ms history.go(-1) safety window. The delayed popstate is then treated as a user-initiated back press, so useLinking matches the cached pre-2FA /settings/security state and calls resetRoot, which unmounts the 2FA RHP and clears the recovery codes — the page "closes" instead of advancing to the Verify/QR step.

The fix changes the navigation to forceReplace: !isWeb:

• Web now uses PUSH, so the createMemoryHistory.go(-1) vs popstate race can never occur, and the browser Back button correctly returns from Verify to the Recovery-codes step.
• Native is unchanged (still REPLACE / forceReplace: true), preserving the back-stack behavior fixed in [BT-128] Migrate forwardTo Routes - 2FA Flow #89608.

Fixed Issues

$ #92564
PROPOSAL: #92564 (comment)

Tests

1. On web in Chrome on macOS, enable Chrome's setting Settings → Downloads → "Ask where to save each file before downloading" (so the native save dialog appears — this is the condition under which the bug reproduces).
2. Sign in with a validated account that does not have 2FA enabled.
3. Go to Account → Security → Two-factor authentication.
4. On the Recovery codes step (Step 1 of 2), click Download codes and pick a location in the save dialog.
5. Verify the app advances to the Verify step (Step 2 of 2) and the 2FA panel stays open (it does not close back to Security). If it doesn't trigger on the first attempt, repeat steps 3–4 (the original bug was intermittent).
6. From the Verify step, click the browser Back button and verify it returns to the Recovery codes step (Step 1) with the panel intact.
7. Regression check for [BT-128] Migrate forwardTo Routes - 2FA Flow #89608 — verify these still work:
   • After completing 2FA during bank-account verification, you are returned to the bank-account verification flow.
   • Pressing Back from the non-USD bank-account setup "finish" step returns to the correct flow (not to the Security page).
8. On native (iOS/Android app), repeat steps 3–6 and verify the behavior is unchanged: Download codes still advances to the Verify step.

• Verify that no errors appear in the JS console

Offline tests

Generating recovery codes requires a server response, so there is no offline-specific behavior for this flow — the change only affects client-side navigation (PUSH vs REPLACE) and does not alter any offline path.

• Verify that no errors appear in the JS console

QA Steps

1. On staging in Chrome on macOS with "Ask where to save each file before downloading" enabled, go to Account → Security → Two-factor authentication.
2. On the Recovery codes step, click Download codes and save the file.
3. Verify the page advances to the Verify step and the panel stays open (does not close). Repeat if it doesn't reproduce the first time.
4. Click the browser Back button from Verify and confirm it returns to the Recovery codes step.
5. Confirm native (iOS/Android) Download codes → Verify still works unchanged.

• Verify that no errors appear in the JS console

PR Author Checklist

• I linked the correct issue in the ### Fixed Issues section above
• I wrote clear testing steps that cover the changes made in this PR
  • I added steps for local testing in the Tests section
  • I added steps for the expected offline behavior in the Offline steps section
  • I added steps for Staging and/or Production testing in the QA steps section
  • I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
  • I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).
• I included screenshots or videos for tests on all platforms
• I ran the tests on all platforms & verified they passed on:
  • Android: Native
  • Android: mWeb Chrome
  • iOS: Native
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
• I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
• I followed proper code patterns (see Reviewing the code)
  • I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
  • I verified that comments were added to code that is not self explanatory
  • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
  • I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I followed the guidelines as stated in the Review Guidelines
• I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
• If any new file was added I verified that:
  • The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory
• If a new CSS style is added I verified that:
  • A similar style doesn't already exist
  • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))
• If new assets were added or existing ones were modified, I verified that:
  • The assets are optimized and compressed (for SVG files, run npm run compress-svg)
  • The assets load correctly across all supported platforms.
• If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
• If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
  • I verified that all the inputs inside a form are aligned with each other.
  • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
• I added unit tests for any new feature or bug fix in this PR to help automatically prevent regressions in this user flow.
• If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

Kapture.2026-06-27.at.06.16.49.mp4

Android: mWeb Chrome

iOS: Native

Kapture.2026-06-26.at.20.36.12.mp4

iOS: mWeb Safari

MacOS: Chrome / Safari

Kapture.2026-06-25.at.16.32.55.mp4

[melvin-bot]

@parasharrajat Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: e9adf2eecb

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Preserve non-settings back paths after success

When this runs on web from a dynamic entry point such as the bank-account 2FA prompt or the required-Xero overlay, using PUSH leaves the recovery-codes screen underneath the later success screen. After the user enables 2FA, browser Back from the success page lands on that root screen; the root page redirects any enabled account to ROUTES.SETTINGS_2FA_ENABLED (lines 73-75), so the user is taken to Settings instead of back to the originating flow. Either keep this intermediate page out of history for non-settings entries or make that enabled-account redirect honor backPath.

Useful? React with 👍 / 👎.

[codecov]

Codecov Report

✅ Changes either increased or maintained existing code coverage, great job!

Files with missing lines	Coverage Δ
...ecurity/TwoFactorAuth/DynamicTwoFactorAuthPage.tsx	0.00% <0.00%> (ø)
... and 12 files with indirect coverage changes

[parasharrajat]

why do we need this?