…6836)

<!--
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**

Align Bridge native Max-button gasless gating with extension by using
Sentinel sendBundle support instead of LD isGaslessSwapEnabled.

<!--
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: null

## **Related issues**

Fixes:

## **Manual testing steps**

```gherkin
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**

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

### **Before**

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

### **After**

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

## **Pre-merge author checklist**

- [ ] 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).
- [ ] 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](https://jsdoc.app/) format
if applicable
- [ ] 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 the Bridge native-token Max-button eligibility logic to depend
on Sentinel `sendBundle` support (plus Smart Transactions/sponsored
quotes), which can alter when users are allowed to max native balances
on different chains.
> 
> **Overview**
> Aligns Bridge native-token Max-button rendering with extension by
replacing the `selectIsGaslessSwapEnabled` feature-flag check with a
Sentinel-based `useIsSendBundleSupported` check, using a memoized
EVM-only `chainId` (non-EVM passes `undefined`).
> 
> Updates and heavily simplifies `useShouldRenderMaxOption` tests to
mock `useIsSendBundleSupported`/`isNonEvmChainId`/`formatChainIdToHex`,
and to validate the new native-token truth table and chain-id wiring.
> 
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
be560bf. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->

<!--
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**
This PR introduces `useTokensBuyability(tokens)` to evaluate buyability
for multiple tokens in a single hook call, and keeps
`useTokenBuyability(token)` as a backward-compatible convenience wrapper
over the batch hook.

`useTokensBuyability` returns buyability as `buyabilityByTokenKey`
(keyed by normalized chain + token address).

Motivation: reduce redundant legacy ramp token fetches when checking
multiple tokens in the same render path. Previously, calling
`useTokenBuyability` N times could trigger repeated legacy useRampTokens
mount-driven fetch behavior.

This change also preserves V2 efficiency by passing `fetchOnMount:
!isV2Enabled`, so the legacy fetch is suppressed when unified buy V2 is
enabled and controller-backed tokens are used.

<!--
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: refactored Ramp buyability to add batched
useTokensBuyability with keyed results and keep useTokenBuyability as a
backward-compatible wrapper, reducing redundant legacy token-cache
fetches for multi-token checks.

## **Related issues**

Fixes: [MUSD-282: mUSD Asset List CTA is spamming the Ramps Tokens API
endpoint](https://consensyssoftware.atlassian.net/browse/MUSD-282)

## **Manual testing steps**

```gherkin
Feature: Batched Ramp token buyability checks

  Scenario: user views mUSD eligibility
    Given user is on a screen that evaluates multiple token buyability states (e.g. Token List)
    Then the app checks buyability of multiple tokens in one hook call
```

## **Screenshots/Recordings**

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

### **Before**
N/A
<!-- [screenshots/recordings] -->

### **After**
When `MM_RAMPS_UNIFIED_BUY_V2_ENABLED="true"` `useMusdRampAvailability`
leverages ramp token cache.
<!-- [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 Ramp buyability evaluation and when the legacy token-cache API
is fetched; regressions could hide/show buy CTAs incorrectly or delay
buyability data if the new fetch gating is misused.
> 
> **Overview**
> Introduces `useTokensBuyability(tokens)` and supporting helpers (e.g.,
`getTokenBuyabilityKey`) to compute Ramp buyability for multiple tokens
in one hook call, while keeping `useTokenBuyability(token)` as a
backward-compatible wrapper.
> 
> Adds a `fetchOnMount` option to `useRampTokens` and uses it from
buyability logic to **skip legacy token-cache fetching when Unified
Ramps V2 is enabled**, reducing repeated API calls.
> 
> Refactors `useMusdRampAvailability` to derive per-chain mUSD
buyability via `useTokensBuyability` (using mUSD token addresses per
chain), and updates/expands tests across Ramp and Earn hooks to cover
the new batching and fetch gating behavior.
> 
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
437bc20. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->

## **Description**

Adds `orderType` (FOK or FAK) to the Predict trade analytics events so
we can track which order type is being used when users place orders.

The order type is determined at preview time based on feature flags
(`permit2Enabled`, `executors`, `fakOrdersEnabled`) and current Permit2
allowance state, then included on the `OrderPreview`. The controller
reads `preview.orderType` and passes it to all three
`trackPredictOrderEvent` calls (submitted, succeeded, failed).

> **Note:** A temporary `hasPermit2Allowance()` check is included in
`previewOrder()` as a workaround. This will be removed in a follow-up PR
once `placeOrder()` guarantees the Permit2 allowance is set
automatically before order submission.

## **Changelog**

CHANGELOG entry: null

## **Related issues**

Fixes: https://consensyssoftware.atlassian.net/browse/PRED-721

## **Manual testing steps**

```gherkin
Feature: Order type analytics tracking

  Scenario: user places a FOK order
    Given the predict feature is enabled with default flags (permit2 disabled)

    When user previews and places an order
    Then the analytics event includes order_type: "FOK" for submitted, succeeded, and failed statuses

  Scenario: user places a FAK order
    Given the predict feature is enabled with permit2Enabled, executors configured, and fakOrdersEnabled all true
    And the user has Permit2 allowance set

    When user previews and places an order
    Then the analytics event includes order_type: "FAK" for submitted, succeeded, and failed statuses
```

## **Screenshots/Recordings**

<!-- Not applicable — analytics-only change with no UI impact -->

### **Before**

<!-- N/A -->

### **After**

<!-- N/A -->

## **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
- [ ] 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 Polymarket `previewOrder`/`placeOrder` logic that determines
`orderType` (FOK vs FAK), which can affect how trades are
submitted/executed under Permit2/fee-collection conditions. While
covered by new unit tests and largely additive for analytics, mistakes
here could lead to incorrect order submission behavior or fee handling.
> 
> **Overview**
> Predict trade analytics now optionally include **`order_type`
(FOK/FAK)** via a new `PredictEventProperties.ORDER_TYPE` key and a
`PredictOrderType` type, with `PredictController.trackPredictOrderEvent`
accepting/passing this value for submitted/succeeded/failed events.
> 
> Polymarket order flow is updated to **compute `orderType` during
`previewOrder()`** (default FOK; switch to FAK when Permit2 config +
`fakOrdersEnabled`, and Permit2 allowance is ready only when fees
require it) and to **use that computed order type in `placeOrder()`**;
related Permit2 allowance checks are wrapped with logging/fallback,
executor selection now uses `crypto.getRandomValues`, and tests are
expanded to validate order-type behavior and analytics property
inclusion.
> 
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
4aa81a4. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->

<!--
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**

The purpose of this PR is to add E2E smoke test coverage for the Unified
Buy V2 flow, validating both routing paths a user can take when
purchasing crypto through the ramps experience.
- Two smoke test scenarios: new user (no prior completed orders) routes
through the native Transak deposit flow (KYC/OTP + bank transfer);
returning user (prior non-Transak aggregator order) routes through the
aggregator WebView buy flow

- New page objects: KYCScreen, OrderDetailsView, ActivitiesView,
ToastModal, extended BuildQuoteView
- Full Transak native flow mocking: auth/login, auth/verify, quotes,
user details, KYC requirements, user limits, create order
- Ramps mock infrastructure refactor: introduced setupDepositOnRampMocks
and setupBuyOnRampMocks as single-purpose helpers;
  - 
setupRegionAwareOnRampMocks retained as the base for build-quote-only
tests; default providerType corrected from native to aggregator

- TestID additions: crypto/fiat amount testIDs moved to
DisplayOrderListItem (the actually-rendered component), testIDs added to
EnterEmail, OtpCode, VerifyIdentity, and ActivitiesView; removed dead
OrdersListTestIds aggregate export


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

## **Related issues**

Fixes:

## **Manual testing steps**

```gherkin
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**

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

### **Before**

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

### **After**

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

## **Pre-merge author checklist**

- [ ] 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).
- [ ] 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](https://jsdoc.app/) format
if applicable
- [ ] 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**
> Mostly E2E test, selector, and mock refactors, but it substantially
changes the on-ramp mocking setup and fixtures used across ramps smoke
tests, which could cause test flakiness or broken flows if assumptions
drift.
> 
> **Overview**
> Adds end-to-end smoke coverage for Unified Buy V2 across both routing
paths: **new users** go through the native Transak KYC/OTP deposit flow,
while **returning users** go through the aggregator (widget/WebView) buy
flow, including verification of the resulting order in the Activity
transfers list and basic analytics assertions.
> 
> Refactors ramps API mocking to provide dedicated helpers
(`setupDepositOnRampMocks`, `setupBuyOnRampMocks`) and expands mocked
endpoints for the native Transak flow (auth, quotes, user/KYC/limits,
order creation, translation, and stateful order polling), while
splitting buy vs deposit order-status mocking.
> 
> Improves Detox automation by adding/centralizing `testID` selectors
for ramps screens (`EnterEmail`, `OtpCode`, `VerifyIdentity`,
`OrderDetails`) and for `OrdersList` rows/amounts, plus new page objects
(`KYCScreen`, `OrderDetailsView`) and enhanced page object actions
(e.g., wait-for-enabled Continue).
> 
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
0b768fe. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->

…AYMENT_METHOD_SELECTED (#26531)

## **Description**

Removes the `offramp-cashout.failing.ts` e2e test and closes the
coverage gap with a new unit test as part of
[MMQA-1492](https://consensyssoftware.atlassian.net/browse/MMQA-1492).

The e2e test was fully skipped (`describe.skip`) and covered two
behaviors on the Aggregator offramp `BuildQuote` screen:

1. **Payment method selection** — tapping the payment method dropdown
and switching from "Debit or Credit" to "SEPA Bank Transfer"
2. **Analytics event tracking** — `OFFRAMP_PAYMENT_METHOD_SELECTED`
event fires with correct properties (`payment_method_id`,
`available_payment_method_ids`, `region`, `location`)

**Existing coverage** in `PaymentMethodSelectorModal.test.tsx`:
- `'tracks RAMPS_PAYMENT_METHOD_SELECTED event when payment method is
selected'` — fires the event with all required properties (buy flow)
- `'does not track RAMPS_PAYMENT_METHOD_SELECTED event when the same
payment method is selected'` — guards against duplicate events
- `'renders for sell flow'` — snapshot test with `isBuy: false`

**Coverage gap identified:** The existing analytics test only exercised
`isBuy: true`, so the `OFFRAMP_PAYMENT_METHOD_SELECTED` event name
branch was never tested. The payload shape was already covered since
it's identical for both flows.

**Gap closed:** Added a new unit test case with `isBuy: false` that
asserts `OFFRAMP_PAYMENT_METHOD_SELECTED` fires with the correct
payload. The `isBuy` ternary branch is now fully covered.

## **Changelog**

CHANGELOG entry: null

## **Related issues**

Fixes: https://consensyssoftware.atlassian.net/browse/MMQA-1492

## **Manual testing steps**

```gherkin
Feature: Ramps offramp-cashout e2e removal with coverage gap closed

  Scenario: user verifies offramp analytics event coverage
    Given the metamask-mobile repository is checked out on the PR branch

    When user runs yarn test app/components/UI/Ramp/Aggregator/components/PaymentMethodSelectorModal/PaymentMethodSelectorModal.test.tsx
    Then all unit tests pass
    And the test "tracks OFFRAMP_PAYMENT_METHOD_SELECTED event when payment method is selected in sell flow" passes
    And the test "tracks ONRAMP_PAYMENT_METHOD_SELECTED event when payment method is selected in buy flow" passes
    And the test "does not track ONRAMP_PAYMENT_METHOD_SELECTED event when the same payment method is selected" passes
```

## **Screenshots/Recordings**

### **Before**

5 tests in `PaymentMethodSelectorModal.test.tsx`:
- `renders correctly`
- `renders without disclaimer when selected payment method has none`
- `renders for sell flow`
- `tracks RAMPS_PAYMENT_METHOD_SELECTED event when payment method is
selected` — misnamed, only tested buy flow
- `does not track RAMPS_PAYMENT_METHOD_SELECTED event when the same
payment method is selected` — misnamed

The `isBuy: false` branch (`OFFRAMP_PAYMENT_METHOD_SELECTED`) was never
exercised. Test names did not match the actual events being asserted.

### **After**

6 tests in `PaymentMethodSelectorModal.test.tsx`:
- `renders correctly`
- `renders without disclaimer when selected payment method has none`
- `renders for sell flow`
- `tracks OFFRAMP_PAYMENT_METHOD_SELECTED event when payment method is
selected in sell flow` — **new**, covers `isBuy: false` with realistic
`location: 'Amount to Sell Screen'`
- `tracks ONRAMP_PAYMENT_METHOD_SELECTED event when payment method is
selected in buy flow` — **renamed** to match actual assertion
- `does not track ONRAMP_PAYMENT_METHOD_SELECTED event when the same
payment method is selected` — **renamed** to match actual assertion

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

[MMQA-1492]:
https://consensyssoftware.atlassian.net/browse/MMQA-1492?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ

<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> **Low Risk**
> Test-only changes: adds/renames unit tests for onramp/offramp
analytics and removes a fully skipped smoke e2e, with no production
logic changes.
> 
> **Overview**
> Adds unit test coverage in `PaymentMethodSelectorModal.test.tsx` to
assert the sell flow fires `OFFRAMP_PAYMENT_METHOD_SELECTED`, and
renames existing assertions to explicitly reference
`ONRAMP_PAYMENT_METHOD_SELECTED`.
> 
> Removes the fully skipped `offramp-cashout.failing.ts` smoke test that
previously attempted to validate off-ramp payment method selection and
analytics.
> 
> <sup>Written by [Cursor
Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit
f166a54. This will update automatically
on new commits. Configure
[here](https://cursor.com/dashboard?tab=bugbot).</sup>
<!-- /CURSOR_SUMMARY -->

---------

Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>