Revert the MMKV major bump that landed in #29195 (RN 0.81.5 upgrade). The v3 -> v4 jump was not required by RN 0.81 / React 19 / Expo SDK 54 and shipped a latent crash in migration 106 (PPOM cleanup) because v4 makes MMKV a type-only export while migration 106 was still calling new MMKV(...) against require('react-native-mmkv').MMKV.

CHANGELOG entry: null

Changes:

• package.json: react-native-mmkv ^4.1.2 -> ^3.2.0 (resolves to 3.3.3) react-native-nitro-modules left pinned at 0.35.5 since react-native-vision-camera and other packages still need the new Nitro version.
• app/store/storage-wrapper.ts: createMMKV() -> new MMKV(), .remove(key) -> .delete(key), drop the as MMKV cast, EventEmitter2 named import restored.
• app/store/migrations/049.ts: factory -> constructor.
• app/store/migrations/106.ts: drop the require + // eslint-disable workaround, use a plain import { MMKV }. Fixes the silent migration failure on devices that had PPOM storage.
• app/store/migrations/136.ts: factory -> constructor, .remove() -> .delete() (this migration was added in feat: persist deeplink attribution with MMKV #29542 after the bump landed, so it needed forward-translation to v3 rather than a true revert).
• app/store/migrations/106.test.ts, 136.test.ts: revert mock factory exports from createMMKV to MMKV.
• app/util/notifications/settings/storage/index.ts: all three callsites swapped from createMMKV(...) to new MMKV(...).
• app/util/test/testSetup.js, testSetupView.js: drop createMMKV from the module-level mock factory (v3 has no such export, so leaving it in would mask real production bugs in tests).
• ios/Podfile.lock: regenerated. NitroMmkv pod + MMKVCore artifact removed; react-native-mmkv v3 pod added.

Verified post-revert: no createMMKV references left in the codebase, no import type { MMKV } left, no v4-style .remove(key) on MMKV instances, lints clean across all touched files. notificationStorage test still uses import { MMKV } for a type annotation, which works since v3 exports MMKV as a class (value + type).

TODO before merge: run the unit-test suite and an iOS/Android smoke build, plus the in-place upgrade canary scenario from #29195 to confirm v3 binaries can still read MMKV files that were written by v4 in any prior dev/internal build (production users are still on v3).

Description

Changelog

CHANGELOG entry:

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.