refactor: extract getBestToken and align Predict payment token selection

[caieu]

Description

The getBestToken token-ranking logic was duplicated between useAutomaticTransactionPayToken (confirmations pay flow) and usePredictDefaultPaymentToken (Predict buy screen). The Predict hook had its own inline selection algorithm that filtered by ERC20 standard, testnet status, and fiat balance — diverging from the shared pay flow's feature-flag-aware ranking (preferred tokens, success rates, minimum balance thresholds).

This PR:

1. Extracts getBestToken into a standalone utility (confirmations/utils/getBestToken.ts) with its own comprehensive test suite (648 lines covering all ranking branches).
2. Rewires usePredictDefaultPaymentToken to call the shared getBestToken instead of reimplementing token selection inline, bringing it in line with useAutomaticTransactionPayToken and gaining feature-flag-driven preferred-token ranking, minimum balance checks, and hardware-wallet handling for free.
3. Introduces MINIMUM_PREDICT_BALANCE_FOR_BET (1.05) to account for combined fees (~$0.05 on a $1 bet) when deciding whether the Predict balance alone is sufficient.
4. Simplifies useAutomaticTransactionPayToken tests — token-ranking edge cases now live in the getBestToken unit tests, so the hook tests focus on integration behavior (calls getBestToken, respects disable, re-selects on account change).

Changelog

CHANGELOG entry: null

Related issues

Fixes:

Manual testing steps

Feature: Predict payment token auto-selection

  Scenario: User with low Predict balance sees best token auto-selected
    Given the user has a Predict balance below $1.05
    And the user has ERC-20 tokens with positive fiat balances

    When the user opens the Predict buy screen
    Then the payment token row shows the highest-ranked available token
    And the selection matches the same token the confirmations pay flow would pick

  Scenario: User with sufficient Predict balance stays on Predict balance
    Given the user has a Predict balance of $5.00 or more

    When the user opens the Predict buy screen
    Then the payment token row shows "Predict balance"
    And no external token is auto-selected

  Scenario: Hardware wallet always resets to Predict balance
    Given the user is connected with a hardware wallet (Ledger/Keystone)
    And the user has a Predict balance of $0

    When the user opens the Predict buy screen
    Then the payment token row shows "Predict balance"
    And no external token is auto-selected

Screenshots/Recordings

Before

N/A

After

N/A

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.

[github-actions]

CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes.

[github-actions]

🔍 Smart E2E Test Selection

⏭️ Smart E2E selection skipped - draft PR

All E2E tests pre-selected.

View GitHub Actions results

[github-actions]

✅ E2E Fixture Validation — Schema is up to date
11 value mismatches detected (expected — fixture represents an existing user).
View details

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
98.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud