fix(confirmations): show Relay exact-input deposit output

[pedronfigueiredo]

Description

Updates Mobile confirmation UX to consume the Pay Controller's normalized input/output semantics instead of reconstructing them from transaction types, quote strategy, or provider-specific quote details.

• Reads TransactionPayTotals.isInputBased from controller state and treats only an explicit true as input-based.
• Shows You receive for input-based quotes and displays the controller's authoritative targetAmount.
• Keeps the entered source amount stable when an input-based Max quote resolves or the confirmation remounts.
• Keeps the existing Total row for output-based, mixed, or unavailable totals.
• Retains the legacy withdrawal fee calculation when totals are output-based or do not expose isInputBased; input-based withdrawals use the controller's authoritative target amount.
• Removes the Mobile-only Relay/Perps/Predict classification hook.

This PR depends on MetaMask/core#9954. Core now:

• uses EXACT_INPUT with sourceTokenAmount for Relay requests without embedded transactions;
• preserves EXACT_OUTPUT for Relay requests with embedded transactions;
• exposes optional TransactionPayQuote.isInputBased and TransactionPayTotals.isInputBased properties; and
• sets aggregate totals as input-based only when every selected quote reports input-based semantics.

Integration status

The committed Mobile branch still uses @metamask/transaction-pay-controller@^26.4.1, so the new runtime behavior remains gated on the published Core release containing #9954. The compatibility type in this branch supports development against the currently installed package and should be removed after that dependency bump.

Mobile now wires both the v26 resolveSourceAmount callback and the v27 getBalance callback through one shared Money Account balance resolver, allowing the committed code to work with either controller API during the transition. The final dependency integration still needs to align @metamask/sentinel-api-service with Core and regenerate/dedupe yarn.lock. Local absolute-path file: dependency changes are for simulator testing only and must not be committed.

Changelog

CHANGELOG entry: Updated input-based confirmations to show the amount received while preserving the total source amount entered

Related issues

Fixes: https://consensyssoftware.atlassian.net/browse/CONF-1782

Manual testing steps

Feature: Controller-owned input-based confirmation totals

  Scenario: Review an input-based Relay deposit
    Given the Pay Controller returns totals with isInputBased set to true
    When the user enters an amount and reviews the confirmation
    Then the entered source amount remains unchanged after the quote resolves
    And the confirmation displays You receive using totals.targetAmount

  Scenario: Review an input-based Max deposit after remounting
    Given the user selected Max for an input-based quote
    When the quote resolves or the confirmation remounts
    Then the input continues to display the controller source amount
    And it does not change to the destination target amount

  Scenario: Review an embedded-transaction Relay quote
    Given Relay embedded transactions require exact-output semantics
    When the user reviews the confirmation
    Then totals.isInputBased is false
    And the existing Total row is displayed

  Scenario: Review a mixed aggregate
    Given at least one selected quote is output-based
    When the user reviews the confirmation
    Then totals.isInputBased is false
    And the existing Total row is displayed

  Scenario: Review an input-based withdrawal
    Given withdrawal token selection is enabled
    And totals.isInputBased is true
    When the user reviews the confirmation
    Then You receive displays totals.targetAmount

  Scenario: Review a legacy or output-based withdrawal
    Given withdrawal token selection is enabled
    And totals.isInputBased is false or unavailable
    When the user reviews the confirmation
    Then You receive retains the existing withdrawal fee calculation

Screenshots/Recordings

N/A — manual device verification remains pending the corresponding published Core package integration.

Before

N/A

After

N/A

Validation

• 108 focused unit tests passed across the changed confirmation components and hooks.
• 12 focused controller initialization and balance-callback tests passed.
• Formatting, focused ESLint, and git diff --check passed.
• yarn lint:tsc passed against the locally linked final Core package after aligning the local Sentinel dependency.
• Final published dependency and lockfile validation remain pending the Core release.

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
  • Considered and not applicable yet: manual device testing is pending Core integration.
• I've tested with a power user scenario
  • Considered and not applicable to this focused confirmation-row change.
• I've instrumented key operations with Sentry traces for production performance metrics
  • Considered and not applicable: this change adds no new asynchronous operation.

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.

[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.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
88.2% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[github-actions]

🧪 Flaky unit test detection

Run history flaky detection

View recent run history

Historical failure rate is a hint, not proof — review each suggestion in context. See the flaky-test-detection skill for the full pattern reference and manual audit workflow.

Failures / runs sampled per window:

File	7d	15d	30d
app/components/Views/confirmations/components/custom-amount/custom-amount-totals/custom-amount-totals.test.tsx	0/113	0/263	0/392
app/components/Views/confirmations/components/rows/receive-row/receive-row.test.tsx	0/113	0/263	0/392
app/components/Views/confirmations/hooks/transactions/useTransactionCustomAmount.test.ts	0/113	0/263	0/392

AI-detected flaky patterns

app/components/Views/confirmations/components/custom-amount/custom-amount-totals/custom-amount-totals.test.tsx

• J4 — waitFor without a real assertion inside (high)
  • The waitFor function is called without any assertions inside, which means it resolves immediately without verifying any conditions, leading to potential false positives in tests.
  • Suggested fix in app/components/Views/confirmations/components/custom-amount/custom-amount-totals/custom-amount-totals.test.tsx:1:

    -await waitFor(() => {});
    +await waitFor(() => {
    +      expect(getByTestId('total-row')).toBeOnTheScreen();
    +    });

app/components/Views/confirmations/components/rows/receive-row/receive-row.test.tsx

• J3 — Missing jest.clearAllMocks() / jest.resetAllMocks() (high)
  • The test does not reset mocks between tests, which can lead to shared state and unexpected behavior across tests.
  • Suggested fix in app/components/Views/confirmations/components/rows/receive-row/receive-row.test.tsx:1:

    -jest.clearAllMocks();
    +beforeEach(() => {
    +      jest.clearAllMocks();
    +    });

app/components/Views/confirmations/hooks/transactions/useTransactionCustomAmount.test.ts

• J1 — Missing act() around async state updates (critical)
  • The updatePendingAmount function is called asynchronously without being wrapped in act(), which can lead to race conditions and unpredictable test outcomes.
  • Suggested fix in app/components/Views/confirmations/hooks/transactions/useTransactionCustomAmount.test.ts:1:

    -await act(async () => {
    -      result.current.updatePendingAmount('123.45');
    -    });
    +await act(async () => {
    +      await result.current.updatePendingAmount('123.45');
    +    });

This check is informational only and does not block merging.