fix(perps): prefer selected evm account

[geositta]

Description

This PR updates Perps account resolution so compliance gated Perps flows evaluate the same EVM account the user currently has selected.

As part of the compliance work, Perps needs to reliably identify the active wallet address before allowing sensitive actions such as deposits, trades, and other account-specific operations. The previous logic derived the address from the selected account group, which could pick a different EVM account than the user-facing selected account when multiple accounts exist in the group.

The solution adds a selected account first lookup: Perps now reads AccountsController:getSelectedAccount when it is an EVM account, and falls back to the existing selected account group behavior when needed. This keeps Perps address resolution aligned with the active wallet while preserving compatibility with the existing account-group path.

Changelog

CHANGELOG entry: Prefer the selected EVM account when resolving Perps account state and compliance-gated actions.

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

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.

[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
85.7% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud