feat(support): adopt support consent flow in RewardsVipRefereeView and LinkedOffDeviceAccountsSheet

[NicolasMassart]

Description

Adopts the support-consent mechanism introduced by the core PR (#33424) in the two @MetaMask/rewards-owned "Contact support" call sites:

• RewardsVipRefereeView: the priority support webview link now routes through useSupportConsent().openSupportWithConsent (falls back to the direct beta Intercom URL when the beta build flag is set).
• LinkedOffDeviceAccountsSheet: the "let us know" contact-support action now routes through the same consent flow (same beta fallback behavior).

This PR is part of a stacked PR series on top of the core support-consent PR (#33424, MCWP-684-support-consent-core). Its base will be retargeted to main once #33424 merges.

Changelog

CHANGELOG entry: null

(Behavior already described in the core PR, #33424.)

Related issues

Fixes: https://consensyssoftware.atlassian.net/browse/MCWP-684

Manual testing steps

Feature: Support consent on rewards contact-support flows

  Scenario: user taps "Contact support" from the VIP referee view
    Given the user is on the Rewards VIP referee view

    When user taps "Contact support"
    Then the support consent sheet is shown before the support webview opens

  Scenario: user taps "let us know" from the linked off-device accounts sheet
    Given the user has opened the linked off-device accounts sheet

    When user taps "let us know"
    Then the support consent sheet is shown before the support webview opens

Screenshots/Recordings

Before

N/A

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

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.

[metamask-ci]

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 tested on Android"). 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.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit cefb2e0. Configure here.}

[github-actions]

🔍 Smart E2E Test Selection

• Selected E2E tags: None (no tests recommended)
• Selected Performance tags: None (no tests recommended)
• Risk Level: low
• AI Confidence: 90%

click to see 🤖 AI reasoning details

E2E Test Selection:
The PR changes are confined to the Rewards feature area (RewardsVipRefereeView, LinkedOffDeviceAccountsSheet, and utils.ts). The changes are a refactoring of support URL logic: extracting inline beta code fence logic (ONLY_INCLUDE_IF(beta)) into a testable utility function getBetaSupportUrl() and integrating the existing useSupportConsent hook for the non-beta path. No new user-facing flows are introduced; behavior is functionally equivalent. There are no existing E2E smoke tests for the Rewards feature area (confirmed by grep). The useSupportConsent hook itself is not modified. All changes are accompanied by unit tests. No shared components (TabBar, navigation, modals, confirmations) are affected in a breaking way. This is a low-risk internal refactoring with no E2E test coverage gap to fill.

Performance Test Selection:
The changes are a refactoring of support URL logic within the Rewards feature. No performance-sensitive flows (app launch, login, onboarding, swaps, asset loading, account list, perps, predictions) are affected. No performance tests are warranted.

View GitHub Actions results

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud