Description

After switching the selected EVM account, the Spending Limit screen's Token selector rendered the "No tokens available" empty state, even when the new account had supported tokens that could be enabled. The root cause was introduced in #30028: BaanxProvider.buildSupportedTokens synthesized the "Not enabled" placeholder rows once at fetch time and stamped them with the account that was selected during the fetch. cardHomeData is not refetched on a plain account switch, so the stale walletAddress on those placeholders no longer matched the new selected account and the downstream filter in selectCardAvailableTokens removed them all.

Rather than triggering a network refetch on every account change (the getCardHomeData call is heavy), this PR moves the placeholder synthesis into the selector layer so the list is recomputed reactively from data that is already in the store.

• BaanxProvider.buildSupportedTokens no longer creates inactive placeholders or takes a currentWalletAddress. Its sole responsibility is now to enrich the real fundingAssets with the matching delegationContract from delegationSettings.
• selectCardAvailableTokens now combines cardHomeData, the selected EVM account, and selectCardFeatureFlag. It returns the filtered real entries plus Inactive placeholders synthesized from delegationSettings via buildDelegationTokenList, each stamped with the currently selected wallet address. Memoization keeps recomputation cheap.
• selectCardLineaUsdcToken is rebased on selectCardAvailableTokens so the Cashback screen also benefits from the synthesized USDC-on-Linea placeholder.

No data-fetching or controller subscription is added; the selector recomputes from already-cached state.

Changelog

CHANGELOG entry: Fixed a bug where the Card spending-limit token selector incorrectly showed "No tokens available" after switching accounts.

Related issues

Refs: #30028

Manual testing steps

Feature: Card spending-limit token selector reflects the selected account

  Scenario: Token list reflects the new account after switching
    Given the Card feature is enabled
      And I have at least two EVM accounts (Account A and Account B)
      And Account A has at least one Card-supported token enabled (e.g. USDC on Linea)
      And Account B has no Card token enabled yet
      And the Card spending-limit screen is open with Account A selected
      And the Token selector shows the supported tokens

    When I switch the selected account to Account B
      And I open the Token selector

    Then the Token selector lists the Card-supported tokens (e.g. USDC on Linea) as "Not enabled" for Account B
      And it does NOT show the "No tokens available" empty state
      And no Card home-data network refetch is triggered by the account switch

  Scenario: Real funding assets keep being shown alongside placeholders
    Given I have an account with at least one delegated Card token (Active)

    When I open the Card spending-limit screen for that account

    Then the Active token is shown with its enabled state
      And any other Card-supported tokens that are not yet enabled appear as "Not enabled" placeholders
      And the placeholders are stamped with the currently selected wallet address

  Scenario: Cashback Linea USDC continues to work
    Given the Card feature is enabled
      And the selected account has not yet enabled USDC on Linea

    When I open the Cashback flow

    Then USDC on Linea is detected as the cashback token (via the synthesized placeholder)
      And the "Linea funding requirement" path renders as expected

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.