…e token regardless of selected network in deeplink flow (#27202)

<!--
Please submit this PR as a draft initially.
Do not mark it as "Ready for review" until the template has been
completely filled out, and PR status checks have passed at least once.
-->

## **Description**

When a user opens the mUSD conversion education screen via deeplink, the
component calls getPaymentTokenForSelectedNetwork() to determine which
token to convert. If the user hasn't selected a specific network (e.g.,
using the "Popular networks" filter), this function can return null —
causing the flow to skip conversion entirely and fall through to the buy
or navigate-home paths, even though the user has convertible tokens.

This fix adds a fallback: when getPaymentTokenForSelectedNetwork()
returns null but conversionTokens is non-empty (guarded by the
hasConvertibleTokens check), the component defaults to the first
available conversion token. This ensures deeplink users are always
routed to the conversion flow when they have eligible tokens.

<!--
Write a short description of the changes included in this pull request,
also include relevant motivation and context. Have in mind the following
questions:
1. What is the reason for the change?
2. What is the improvement/solution?
-->

## **Changelog**

<!--
If this PR is not End-User-Facing and should not show up in the
CHANGELOG, you can choose to either:
1. Write `CHANGELOG entry: null`
2. Label with `no-changelog`

If this PR is End-User-Facing, please write a short User-Facing
description in the past tense like:
`CHANGELOG entry: Added a new tab for users to see their NFTs`
`CHANGELOG entry: Fixed a bug that was causing some NFTs to flicker`

(This helps the Release Engineer do their job more quickly and
accurately)
-->

CHANGELOG entry: n/a

## **Related issues**

Fixes: https://consensyssoftware.atlassian.net/browse/MUSD-496

## **Manual testing steps**

```gherkin
Feature: mUSD Deeplink Conversion Fallback

  Background:
    Given the user has convertible stablecoin tokens in their wallet
    And the user goes through deeplink flow  `xcrun simctl openurl booted "metamask://earn-musd"`

  Scenario: Deeplink converts using first available token when no network-specific token exists
    Given the user has not selected a specific network filter
    And getPaymentTokenForSelectedNetwork returns null
    When the user opens the mUSD conversion deeplink
    And the education screen is displayed
    And the user presses the primary "Get Started" button
    Then the conversion flow initiates with the first convertible token
    And the education screen is marked as seen

  Scenario: Deeplink converts using network-specific token when available
    Given the user has selected a specific network
    And getPaymentTokenForSelectedNetwork returns a valid token
    When the user opens the mUSD conversion deeplink
    And the education screen is displayed
    And the user presses the primary "Get Started" button
    Then the conversion flow initiates with the network-specific token
    And the education screen is marked as seen
```

## **Screenshots/Recordings**

<!-- If applicable, add screenshots and/or recordings to visualize the
before and after of your change. -->

### **Before**


https://consensys.slack.com/files/U06EZC2Q81X/F0AKSVBC51P/screenrecording_03-09-2026_10-22-25_1.mp4

<!-- [screenshots/recordings] -->

### **After**


https://github.com/user-attachments/assets/4adb4590-20e1-4555-b652-201edff1d8c1

<!-- [screenshots/recordings] -->

## **Pre-merge author checklist**

- [x] I've followed [MetaMask Contributor
Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile
Coding
Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md).
- [x] I've completed the PR template to the best of my ability
- [x] I've included tests if applicable
- [x] I've documented my code using [JSDoc](https://jsdoc.app/) format
if applicable
- [x] I've applied the right labels on the PR (see [labeling
guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)).
Not required for external contributors.

## **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.


<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> **Medium Risk**
> Changes deeplink routing to auto-select a fallback conversion token
and alters conversion-token ordering, which can affect which asset is
preselected/converted for users in edge cases. Scope is limited to mUSD
conversion entry flow and covered by added tests, but impacts
user-facing navigation/selection logic.
> 
> **Overview**
> **mUSD deeplink conversion now falls back to a wallet token instead of
skipping conversion.** When `getPaymentTokenForSelectedNetwork()`
returns `null`, the education deeplink flow uses the first
`conversionTokens` entry (validated/normalized via
`safeFormatChainIdToHex` + `toChecksumAddress`) to proceed with
`convert` rather than falling through to *buy* or *home*.
> 
> **Conversion token ordering is updated.** `useMusdConversionTokens`
now sorts eligible conversion tokens by descending fiat balance so the
fallback token is deterministically the highest-value option.
> 
> **Tests updated/added** to cover the fallback conversion behavior and
the buy/home fall-through when the fallback token is invalid (e.g.,
missing `chainId`), plus token sorting by fiat balance.
> 
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
5a5c5da. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->