Description

Migrates the Stake screen and modal navigators from @react-navigation/stack to @react-navigation/native-stack(POC), and replaces getStakingNavbar + useEffect(setOptions(...)) with an in-screen HeaderStandard on three Stake flows.

Why: Setting headers via useEffect + setOptions on native stack causes a visible flicker on first paint (the default native header renders, then is replaced); for these screens we now configure headerShown: false at the route level and render the header in-screen with HeaderStandard, which eliminates the flicker.

What changed

1. Stake/routes/index.tsx:

• createStackNavigator → createNativeStackNavigator for both StakeScreenStack and StakeModalStack.
• Modal stack switched to clearNativeStackNavigatorOptions + transparentModalScreenOptions (native-stack equivalents of the prior preset).
• screenOptions.headerShadowVisible: false.
• headerShown: false on STAKE, STAKE_CONFIRMATION, UNSTAKE_CONFIRMATION, EARNINGS_HISTORY.

2. StakeConfirmationView, UnstakeConfirmationView, StakeEarningsHistoryView: replaced legacy header setup with HeaderStandard; back button preserves the existing analytics events (STAKE_CONFIRMATION_BACK_CLICKED, UNSTAKE_CONFIRMATION_BACK_CLICKED) via useAnalytics.
   Note I am leaving migration EarnWithDrawInputView.tsx out on purpose because this navbar has more logic so it's better for the team to do the migration

3. UnstakeConfirmationView.styles.ts: mainContainer height: '100%' → flex: 1 so the footer (Cancel / Continue) lays out correctly under the new flex parent + HeaderStandard.

4. EarnInputView: removed the now-redundant useEffect(() => navigation.setOptions({ headerShown: false })) (the route owns it).

5. Tests: navigation mocks now include goBack; StakeEarningsHistoryView.test.tsx was rewritten to assert on the rendered header title instead of setOptions / getStakingNavbar (which the screen no longer calls).

Android test build: https://github.com/MetaMask/metamask-mobile/actions/runs/25891826048

Changelog

CHANGELOG entry:null

Related issues

Fixes:

Manual testing steps

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

Please note that some of these flows are not representing what app is behaving right now. I hardcoded some of the screens to see the navigation behaviours

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.