Description

Extends the Crypto section of the redesigned Pay with bottom sheet so the user-selected token from the existing Other assets picker is reflected back as its own row the next time the bottom sheet opens.
When the selected pay token diverges from the auto-selected preferred candidate, both rows render: the preferred token row (no checkmark) and a separate user-selected token row (with the checkmark). When the user re-selects the preferred token, the bottom sheet collapses back to a single row — preferred with the checkmark. Tapping the preferred token row inside the bottom sheet selects it directly, with an idempotency guard that avoids refiring gas-fee estimates when the row is already selected.
Scoped to the current transaction only: no new persistence layer is introduced. The selection lives on TransactionPayController's per-transaction state — the same source the existing PayWithModal already writes to via setPayToken. Origin (user vs automatic) is derived by comparing payToken to the automatic candidate from useAutomaticTransactionPayToken.

The bottom sheet now dismisses itself whenever a token is selected, so the only path that leaves the picker open is the header X. Two paths covered:

• Tap a row inside the sheet: the preferred-row onPress calls selectToken and then navigation.goBack(). Idempotent taps (already-selected) still dismiss — a token-row tap is treated as a "done picking" signal.
• Pick a token inside the underlying PayWithModal: new useDismissOnPayTokenChange() hook snapshots payToken on mount and calls navigation.goBack() whenever the value diverges. Wired into PayWithBottomSheet. The modal still closes itself first via its existing handleTokenSelect path, then the sheet sees the change and pops, returning the user to the confirmation screen.
  No double-dismiss: the row-tap path goes through setPayToken too, but the section hook calls goBack() first, so by the time the effect re-runs the route is already popped.

Changelog

CHANGELOG entry:

Related issues

Fixes: https://consensyssoftware.atlassian.net/browse/CONF-1360

Manual testing steps

Feature: my feature name

  Scenario: user [verb for user action]
    Given [describe expected initial app state]

    When user [verb for user action]
    Then [describe expected outcome]

Screenshots/Recordings

Before

After

Pre-merge author checklist

• I've followed MetaMask Contributor Docs and MetaMask Mobile Coding Standards.
• I've completed the PR template to the best of my ability
• I've included tests if applicable
• I've documented my code using JSDoc format if applicable
• I've applied the right labels on the PR (see labeling guidelines). Not required for external contributors.

Performance checks (if applicable)

• I've tested on Android
  • Ideally on a mid-range device; emulator is acceptable
• I've tested with a power user scenario
  • Use these power-user SRPs to import wallets with many accounts and tokens
• I've instrumented key operations with Sentry traces for production performance metrics
  • See trace() for usage and addToken for an example

For performance guidelines and tooling, see the Performance Guide.

Pre-merge reviewer checklist

• I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed).
• I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.