feat: Button migration (no codeowners, p2)

[kirillzyusko]

Description

Use Button component from DSRN (no codeowners scope).

Changelog

CHANGELOG entry: null

Related issues

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

Manual testing steps

Feature: button migrations

  Scenario: user sees modified files
    Given user interacts with Button components changes in this PR

    When user sees the new Button implementation
    Then he doesn't see a difference (visual) from previous implementation

Screenshots/Recordings

Before

Simulator.Screen.Recording.-.iPhone.17.Pro.-.2026-06-12.at.15.13.12.mov

After

Simulator.Screen.Recording.-.iPhone.17.Pro.-.2026-06-12.at.15.11.47.mov

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.

---

Note

Low Risk
Mechanical import and prop renames only; handlers and test IDs are unchanged, with manual testing aimed at visual parity.

Overview
This PR continues the DSRN Button migration (DSYS-445) in screens that are outside codeowner-heavy areas. Every touched file drops component-library Button in favor of @metamask/design-system-react-native.

The updates are API-only: ButtonVariants → ButtonVariant, label → children, width={ButtonWidthTypes.Full} → isFullWidth, and legacy flags like loading / disabled → isLoading / isDisabled. Existing testIDs, onPress handlers, and variants (including isDanger on disconnect) are preserved.

Coverage spans bottom sheets and modals (What’s New, browser tab limit, simulation change, origin spam, multi-RPC, success/error), account permissions flows, add-account and network management footers, hardware wallet awaiting-app/confirmation steps, dev AES crypto test form, and sample-feature demos. No new user-facing behavior is introduced—intent is visual parity with the old buttons.

^{Reviewed by Cursor Bugbot for commit bd7c260. 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: SmokeAccounts, SmokeWalletPlatform, SmokeNetworkAbstractions, SmokeMultiChainAPI, SmokeNetworkExpansion, SmokeConfirmations, SmokeBrowser
• Selected Performance tags: None (no tests recommended)
• Risk Level: medium
• AI Confidence: 85%

click to see 🤖 AI reasoning details

E2E Test Selection:
This PR migrates Button components from the internal component-library/components/Buttons/Button to @metamask/design-system-react-native's Button across 18 files. The API changes include: enum rename (ButtonVariants → ButtonVariant), prop changes (label → children, width={ButtonWidthTypes.Full} → isFullWidth, loading → isLoading). While these are API-level migrations rather than logic changes, they affect the rendered UI of buttons in critical user flows and could introduce visual regressions or broken interactions if the new component behaves differently.

Affected flows and corresponding tags:

1. HardwareWallet AwaitingAppContent/AwaitingConfirmationContent — QR hardware wallet flows (continue/cancel buttons). Affects SmokeAccounts (QR hardware wallet account addition).

2. AccountPermissions (ConfirmRevokeAll, ConnectionDetails, PermittedNetworksInfoSheet) — dApp permission management buttons (disconnect, got it). Affects SmokeNetworkAbstractions (chain permissions UI), SmokeMultiChainAPI (session management), SmokeNetworkExpansion (multi-chain dApp connections).

3. AddNewAccount — Account creation cancel/confirm buttons. Affects SmokeAccounts (creating new accounts), SmokeWalletPlatform (multi-SRP account management).

4. Browser MaxBrowserTabsModal — Browser tab limit modal button. Affects SmokeBrowser.

5. ChangeInSimulationModal — Transaction simulation change modal (reject/proceed buttons). Affects SmokeConfirmations.

6. MultiRpcModal — Multi-RPC migration modal accept button. Affects SmokeNetworkAbstractions.

7. NetworkDetailsView / NetworksManagementView — Network save/add buttons. Affects SmokeNetworkAbstractions.

8. OriginSpamModal — Origin spam filter modal (block/continue buttons). Affects SmokeBrowser (browser security), SmokeConfirmations (dApp request handling).

9. SuccessErrorSheet — Generic success/error sheet buttons used across swap, stake, and confirmation flows. Affects SmokeConfirmations.

10. WhatsNewModal — What's New modal button. Affects SmokeWalletPlatform.

11. SampleFeature / AesCryptoTestForm — Developer/test utilities only, no production E2E test impact.

The SmokeSwap and SmokeStake tags were considered for SuccessErrorSheet but since the sheet is a generic component and the core swap/stake logic is unchanged, SmokeConfirmations covers the confirmation-related aspects adequately. SmokeBrowser is selected for MaxBrowserTabsModal and OriginSpamModal changes.

Performance Test Selection:
This PR only migrates Button component imports from the internal component library to @metamask/design-system-react-native. The changes are purely UI component API migrations (prop renames, children pattern) with no changes to data fetching, state management, rendering performance, or app launch flows. No performance-sensitive code paths are affected.

View GitHub Actions results