fix(ramps): payment methods not loading after provider change when token unsupported

[amitabh94]

Description

Problem: After changing provider in the Buy flow (e.g. from "Change provider" in the Token Not Available modal), payment methods sometimes never load and the user can see an internal error. This happens when the selected token is not supported by the new provider: the controller still requested payment methods using the current (unsupported) token’s assetId, so the API failed or returned empty and payment methods stayed cleared.

Root cause:

1. setSelectedProvider(providerId) called getPaymentMethods(regionCode, { provider: provider.id }) without passing assetId. getPaymentMethods then used assetId from state (state.tokens.selected?.assetId). So the request was (newProvider + old selected token). If that token isn’t supported by the new provider, the payment-methods API can fail or return empty → payment methods never load.
2. getPaymentMethods only applied the response when both tokenSelectionUnchanged and providerSelectionUnchanged were true. When we later fix (1) by requesting with a fallback assetId (a token the new provider supports), the response would have tokenSelectionUnchanged === false, so we never applied the result and the UI stayed in loading/error.

Solution:

1. setSelectedProvider: When fetching payment methods for the new provider, use an assetId the new provider supports: the selected token if it’s in provider.supportedCryptoCurrencies, otherwise the first supported asset. Pass that explicitly to getPaymentMethods so the API succeeds.
2. getPaymentMethods (update block): Apply the returned payment methods whenever providerSelectionUnchanged is true (not only when token also matches). When we used a fallback assetId, reset the selected payment method to the first in the list so the UI has a valid selection.

Files changed:

• packages/ramps-controller/src/RampsController.ts – setSelectedProvider: compute and pass supported assetId for payment methods; getPaymentMethods: apply payment methods when provider matches, and set selected to first when token didn’t match or selection invalid.
• packages/ramps-controller/CHANGELOG.md – Fixed entry for payment methods not loading after provider change.

Changelog

CHANGELOG entry added under Fixed: Fix payment methods not loading after changing provider when the selected token is not supported by the new provider; controller now uses a supported asset for the request and still applies the response when provider matches.

Related issues

• Fixes: TRAM-3314 – Fix payment methods loading issue after provider change (internal error when token not available with current provider).
• Related: TRAM-3315 – SOL/payment methods not loading (same class of issue: payment methods/providers not loading in Buy flow).

Manual testing steps

1. Provider change when token not supported

   • Open Buy flow, select a token (e.g. SOL or a token only supported by provider A).
   • Select or land on a provider that does not support that token → Token Not Available modal appears.
   • Tap "Change provider" and choose a different provider that supports other tokens (e.g. ETH).
   • Expected: Payment methods load and the Amount Input screen shows payment method options (and Token Not Available modal if the selected token is still unsupported by the new provider). No internal error; user can change token or provider again.

2. Provider change when token is supported

   • Same as above but choose a provider that does support the current token.
   • Expected: Payment methods load as before; no regression.

3. SOL / non-EVM (TRAM-3315)

   • Region where providers support SOL; select SOL and a provider that supports it.
   • Expected: Payment methods and quotes load. If the backend still fails for certain chains, that is a separate API/backend concern; this change ensures we don’t send an unsupported token+provider pair from the controller.

Pre-merge author checklist

• I've followed MetaMask Contributor Docs and project coding standards.
• I've completed the PR template to the best of my ability.
• I've included tests if applicable (existing setSelectedProvider/getPaymentMethods tests cover current behavior; new edge case could be added in a follow-up).
• I've documented my code (JSDoc / inline comments) where relevant.

Pre-merge reviewer checklist

• Manually tested the PR (build, run app, reproduce provider-change flow).
• Confirm this PR addresses the payment-methods-not-loading and internal error after provider change when token is unsupported.