Description

This change replaces the temporary HeaderCompactStandard component with HeaderStandard from @metamask/design-system-react-native on Earn-related surfaces.

Reason: Align Earn UI with the MetaMask design system and reduce reliance on component-library/components-temp for standard headers.

What changed: HeaderStandard is used for the Lending “How it works” bottom sheet, the Earn input screen header (back button and end actions), and the Earn token list bottom sheet. Behavior is intended to match the previous header (title, back/close, analytics-related tests unchanged aside from naming). Unit test comments and a describe block name were updated to reference HeaderStandard.

Changelog

CHANGELOG entry: null

Related issues

Fixes: https://consensyssoftware.atlassian.net/browse/DSYS-699

Manual testing steps

Feature: Earn headers use design system HeaderStandard

  Scenario: Earn input screen header matches prior behavior
    Given the user is on the Earn flow and opens the amount/input screen (e.g. stake or supply)
    When the user views the screen header and uses the back control
    Then the header shows the expected title and navigation behaves as before

  Scenario: Lending “How it works” modal
    Given the user opens the Lending learn-more / “How it works” bottom sheet from Earn
    When the user views the header and taps close
    Then the sheet dismisses as before

  Scenario: Earn token selection bottom sheet
    Given the user opens the token list bottom sheet (e.g. select token to supply or withdraw)
    When the user views the header title and uses the close control
    Then the sheet closes as before and titles match the prior copy for the flow

Screenshots/Recordings

Before

After

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
  • Ideally on a mid-range device; emulator is acceptable
• I've tested with a power user scenario
  • Use these power-user SRPs to import wallets with many accounts and tokens
• I've instrumented key operations with Sentry traces for production performance metrics
  • See trace() for usage and addToken for an example

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.