feat(qa): reduce performance CI to one build per platform (MMQA-1667)

[javiergarciavera]

Description

Performance CI currently produces four app builds per run (Android/iOS × with-SRP / without-SRP). This PR cuts that to one build per platform by serving wallet state at test runtime through CommandQueueServer and SrpProfile:

• onboarding — no vault init (fresh onboarding)
• performance — pre-imported wallet for login/imported-wallet tests
• mm-connect — dedicated SRP for MM Connect scenarios

Key changes:

• Consolidate BrowserStack build workflows to a single Bitrise build per platform using main-e2e-bs-unified in builds.yml
• Wire commandQueueServer Playwright fixture so all performance specs start CQS before Appium launches the app
• Enable BrowserStack Local for all performance jobs (required for CQS reachability from cloud devices)
• Add iOS ATS relaxation for e2e builds via configure-ats.sh (fixes the original iOS HTTP blocker)
• Fail fast in generateSkipOnboardingState when IS_TEST_BUILD=true but no SRP profile is fetched

Expected impact: ~50% fewer performance builds (e.g. ~392 → ~196 builds/day at prior Apr 8 scale).

Changelog

CHANGELOG entry: null

Related issues

Fixes: MMQA-1667

Manual testing steps

Feature: Single-build performance CI

  Scenario: CI produces one build per platform
    Given run-performance-e2e.yml is triggered via workflow_dispatch
    When the build phase completes
    Then exactly one Android and one iOS Bitrise build are produced (not four)

  Scenario: Onboarding tests use ONBOARDING profile
    Given a unified performance build with IS_TEST_BUILD=true
    When android-onboarding / ios-onboarding Playwright projects run with BrowserStack Local
    Then CommandQueueServer serves SrpProfile.ONBOARDING
    And the app lands on onboarding without vault initialization

  Scenario: Login tests use PERFORMANCE profile
    Given the same unified build URL is used for imported-wallet tests
    When browserstack-android / browserstack-ios projects run
    Then CommandQueueServer serves SrpProfile.PERFORMANCE
    And the app pre-imports ADDITIONAL_SRP_1 and unlocks with PREDEFINED_PASSWORD

  Scenario: MM Connect tests use MM_CONNECT profile
    Given MM_CONNECT_SRP_1 is baked into the build
    When mm-connect-*-browserstack projects run
    Then CommandQueueServer serves SrpProfile.MM_CONNECT
    And the RN playground dapp is reachable via BrowserStack Local

Pre-merge CI validation (recommended):

# workflow_dispatch on run-performance-e2e.yml with:
# performance_tags: ["@PerformanceLaunch"]

Screenshots/Recordings

N/A — CI/test infrastructure change; no user-facing UI changes.

Before

Four BrowserStack builds per performance run (with-SRP / without-SRP × Android / iOS).

After

Two BrowserStack builds per performance run (one Android + one iOS), with wallet state selected at runtime via CommandQueueServer.

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

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.

Made with Cursor

[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 documented my code using JSDoc format 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.