fix(perps): use selected EVM account for withdraw confirmation batch

[dan437]

Description

Perps Withdraw intermittently fails immediately on tap with a "Something went wrong / Your withdrawal wasn't started." toast (recoverable, with "Try again"), reported on v7.79.1+ (CONF-1543).

Root cause (confirmed via Sentry). The underlying failure is Error: Can't process batch (JSON-RPC -32603) — Sentry issue METAMASK-MOBILE-5PRH, 111 users / 423 events, spanning 7.77–7.81 including 7.79.0. The stack is addTransactionBatch → addTransactionBatchWithHook → throw, and breadcrumbs show it fires ~120 ms after the tap with no failing RPC beforehand, so it is a deterministic logic throw, not a network blip.

usePerpsWithdrawConfirmation creates a dummy perpsWithdraw transfer on Arbitrum via addTransactionBatch({ disableHook: true, disableSequential: true }). With both publish hooks disabled, that request can only be created through the EIP-7702 path. The controller takes that path only when doesAccountSupportEIP7702(messenger, from) is true — i.e. from is present in KeyringController.state.keyrings with a supported keyring type (HD Key Tree / Simple Key Pair / Money Keyring). Otherwise it falls into addTransactionBatchWithHook, finds no publish hook, and throws Can't process batch.

The withdraw used selectSelectedInternalAccountAddress for from, which returns the globally selected internal account of any type. When the selected account in the group is non-EVM (e.g. a Solana/Snap account), from is not an EIP-7702-capable EVM keyring → Can't process batch.

Fix. Resolve from from the selected account group's EVM account via selectSelectedInternalAccountByScope(state)('eip155:1') (the selector the rest of Perps already uses, e.g. PerpsConnectionManager), with a fallback to the previously selected account to avoid regressions.

Note: a second, time-varying sub-cause of the same throw is a locked / not-yet-populated keyring at tap time — this feature:perps error set is also dominated by wallet is locked / KEYRING_LOCKED. That is a broader platform concern, out of scope here; the existing goBack() + retryable toast remains the safety net for it. Opened as a draft for team review of the approach.

Changelog

CHANGELOG entry: Fixed an intermittent error when tapping Withdraw on Perps that could prevent the withdrawal flow from starting

Related issues

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

Manual testing steps

Feature: Perps withdraw uses the selected group's EVM account

  Scenario: Withdraw starts when a non-EVM account is selected in the group
    Given a wallet whose selected account group has both an EVM and a non-EVM (e.g. Solana) account
    And Perps "withdraw to any token" is enabled with funds on HyperLiquid
    And the non-EVM account is the selected account

    When the user opens Perps and taps Withdraw
    Then the withdraw confirmation (CustomAmount) opens
    And no "Your withdrawal wasn't started" toast is shown

Screenshots/Recordings

Before

N/A — no device build produced for this change. Production occurrences are tracked in Sentry issue METAMASK-MOBILE-5PRH.

After

N/A

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.

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

[mm-token-exchange-service]

PR template — items to address before "Ready for review"

Warnings — informational, address before merging:

• Pre-merge author checklist has unchecked items (e.g. "I've included tests if applicable"). Every box must be consciously checked — see docs/readme/ready-for-review.md.

See docs/readme/ready-for-review.md for the full Definition of Ready for Review.