fix(ramps): update entry points to use goToBuy

[amitabh94]

Description

Draft scaffold PR for TRAM-3538: update the relevant Ramps entry points to use goToBuy() for add funds card and new order order details flows.

This PR currently contains only an empty scaffold commit so implementation can start from a clean branch based on main.

Changelog

CHANGELOG entry: null

Related issues

Fixes: https://consensyssoftware.atlassian.net/browse/TRAM-3538

Manual testing steps

Feature: Ramps goToBuy entry points

  Scenario: implementation pending
    Given this PR is currently a draft scaffold
    When implementation is added
    Then manual testing steps should be updated for add funds card and order details entry points

Screenshots/Recordings

Before

N/A - implementation pending.

After

N/A - implementation pending.

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
• I've tested with a power user scenario
• I've instrumented key operations with Sentry traces for production performance metrics

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.

Made with Cursor

---

Note

Medium Risk
Changes the card "Fund with cash" entry point from the legacy deposit navigation to unified goToBuy routing, which can alter which ramp flow users land in and affects analytics/tracing emitted on tap.

Overview
Updates the Card add-funds bottom sheet so the cash funding option uses useRampNavigation().goToBuy() (passing a parsed ramp intent derived from the priorityToken) instead of the legacy deposit-specific entry point.

Adjusts analytics/tracing for this entry point: ramp_type now reports BUY/UNIFIED_BUY/UNIFIED_BUY_2 based on unified flags, and the Sentry trace switches from LoadDepositExperience to LoadRampExperience with rampType: BUY tags. Tests are updated to mock unified flags and assert the new navigation + event payloads.

^{Reviewed by Cursor Bugbot for commit c2d094d. Bugbot is set up for automated code reviews on this repo. Configure here.}

[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

• Selected E2E tags: SmokeMoney
• Selected Performance tags: None (no tests recommended)
• Risk Level: medium
• AI Confidence: 88%

click to see 🤖 AI reasoning details

E2E Test Selection:
The changes are confined to the Card's AddFundsBottomSheet component:

1. Navigation change: goToDeposit → goToBuy with a RampIntent derived from the priority token's CAIP chain ID and address. This changes the routing behavior of the "Fund with cash" button in the Card Add Funds flow.

2. Analytics update: ramp_type now correctly reflects 'BUY', 'UNIFIED_BUY', or 'UNIFIED_BUY_2' based on feature flags (previously was always 'DEPOSIT' for non-V2 unified).

3. Trace name update: LoadDepositExperience → LoadRampExperience with RampType.BUY tag.

4. New hook: useRampsUnifiedV1Enabled added to support the three-way ramp type selection.

The existing E2E test (tests/smoke/card/card-home-add-funds.spec.ts) is tagged with SmokeMoney and tests the Add Funds bottom sheet visibility. The analytics expectations don't check ramp_type specifically, so the test should still pass. However, the navigation change (deposit → buy flow) needs validation to ensure the Card Add Funds flow still works end-to-end.

No SmokeSwap or SmokeConfirmations are needed here since the E2E test only validates the bottom sheet appearance, not the full transaction flow. The changes are unit-tested and the E2E test covers the UI surface adequately with SmokeMoney.

Performance Test Selection:
The changes are limited to navigation routing logic and analytics tracking within the AddFundsBottomSheet component. No UI rendering performance, list rendering, or data loading patterns are affected. No performance tests are warranted.

View GitHub Actions results

[sonarqubecloud]

Quality Gate failed

Failed conditions
72.7% Coverage on New Code (required ≥ 80%)

See analysis details on SonarQube Cloud