refactor: rename Controller types to MessengerClient types

[cryptodev-2s]

Description

Rename type definitions in Engine/types.ts to reflect that the init system handles all messenger clients (controllers + services), not just controllers. All consumer imports updated accordingly.

PR 1 of 4 in a series that updates the init system API to use "messenger client" terminology:

• PR 1 (this): Core type renames (Controller → MessengerClient, ControllerInitFunction → MessengerClientInitFunction, etc.)
• PR 2: CONTROLLER_MESSENGERS → MESSENGER_FACTORIES
• PR 3: initModularizedControllers → initMessengerClients + utils/Engine.ts renames
• PR 4: Property renames (controller → messengerClient, getController → getMessengerClient) in all init files + tests

Relates to WPC-916.

Changelog

CHANGELOG entry: null

Related issues

Fixes: https://consensyssoftware.atlassian.net/browse/WPC-916

Manual testing steps

N/A — no runtime behavior change.

Screenshots/Recordings

N/A — no UI changes.

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.

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.

---

Note

Medium Risk
Broad mechanical type renames across many engine init modules and tests; low behavioral risk but moderate integration risk if any downstream code still expects the old Controller* types.

Overview
Updates the Engine init type API to use messenger client terminology: Controllers �� MessengerClients, ControllerName �� MessengerClientName, ControllerInitRequest/ControllerInitFunction �� MessengerClientInitRequest/MessengerClientInitFunction, and related mapping/request types in app/core/Engine/types.ts.

Propagates the rename through all affected init implementations and unit tests (e.g., accountsControllerInit, bridgeControllerInit, TransactionControllerInit, etc.) plus test utilities, without changing initialization logic beyond updated type annotations.

^{Reviewed by Cursor Bugbot for commit e97d56c. Bugbot is set up for automated code reviews on this repo. Configure here.}

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

[github-actions]

🔍 Smart E2E Test Selection

• Selected E2E tags: SmokeAccounts, SmokeConfirmations, SmokeWalletPlatform
• Selected Performance tags: None (no tests recommended)
• Risk Level: low
• AI Confidence: 92%

click to see 🤖 AI reasoning details

E2E Test Selection:
This PR is a pure TypeScript type rename refactoring across 100 controller init files in app/core/Engine/controllers/. The change is exclusively:

• ControllerInitFunction → MessengerClientInitFunction
• ControllerInitRequest → MessengerClientInitRequest

Every single diff examined shows ONLY this import rename and the corresponding type annotation update. No controller logic, initialization order, state schemas, messenger configurations, Redux sync, or runtime behavior was changed.

This is a compile-time only change - TypeScript type aliases are erased at runtime. The actual controller initialization functions remain identical in behavior.

Risk factors:

1. The change touches 100 files across ALL controllers (network, keyring, accounts, permissions, bridge, perps, predict, card, ramps, identity, etc.)
2. If the rename was incomplete or introduced a type mismatch, it could cause TypeScript compilation errors that would prevent the app from building
3. However, since TypeScript would catch any issues at build time (not runtime), E2E tests are not the right validation mechanism

Conservative approach: Running a minimal set of smoke tests covering core wallet functionality (accounts, confirmations, wallet platform) to verify the app initializes correctly and core flows work. This covers the most critical controller domains (KeyringController, AccountsController, NetworkController, TransactionController) that were renamed.

No performance tests are needed as this is a pure type rename with zero runtime impact on rendering, data loading, or app performance.

Performance Test Selection:
This is a pure TypeScript type rename refactoring (ControllerInitFunction → MessengerClientInitFunction) with no runtime behavior changes. Type aliases are erased at compile time and have zero impact on app performance, rendering, data loading, or any measurable performance metric. 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

[github-actions]

✅ E2E Fixture Validation — Schema is up to date
16 value mismatches detected (expected — fixture represents an existing user).
View details

[ccharly]

LGTM for accounts

[ieow]

lgtm

[saustrie-consensys]

Looks like a simple change. I would like to locally test this via my iOS simulator. What user flow journey would this affect?

[cryptodev-2s]

Looks like a simple change. I would like to locally test this via my iOS simulator. What user flow journey would this affect?

These are purely variable renames. The flows should not be impacted in any case. The build would have failed if we were still using the old names in some files. I’d suggest running a simple test, but for this kind of change, where a variable used in almost all flows is being renamed, I would rely more on reviewing the code itself to catch anything that might still be using the old name

[saustrie-consensys]

lgtm

[NicolasMassart]

found 2 naming inconsistencies that could be fixed in this PR

[cryptodev-2s]

found 2 naming inconsistencies that could be fixed in this PR

Here are the follow-up PRs that are currently waiting for this one to merge:

• refactor: rename CONTROLLER_MESSENGERS to MESSENGER_FACTORIES #28641
• refactor: rename initModularizedControllers to initMessengerClients and update result properties #28645

Could I address them in #28641 instead?

Otherwise, it’s going to be much harder to get 13 reviews again.

[NicolasMassart]

approved given the changes will be done in followup PRs

[caieu]

LGTM