fix: network enablement imparity

[juanmigdr]

Explanation

NetworkEnablementController's default state had Sei Mainnet (0x531) enabled, but NetworkController has no built-in client for 0x531. This created a silent inconsistency: the enablement layer said "Sei is on" while the network layer had no idea what Sei was.

This was discovered during a performance investigation in MetaMask Mobile — Engine.lookupEnabledNetworks() calls findNetworkClientIdByChainId() for each enabled chain, which threw synchronously on 0x531 and silently crashed the entire probe. The full story and the defensive fix for existing users is in the companion PR: MetaMask/metamask-mobile#33379.

This PR removes SeiMainnet from getDefaultNetworkEnablementControllerState so fresh installs start with a consistent state. Sei remains in POPULAR_NETWORKS and can still be added by the user. Persisted state for existing users is unchanged — only the initial default changes.

Removal rather than setting false is intentional: the default map should only list networks that NetworkController actually manages. A false entry would still assert an opinion about a network the controller doesn't know about.

A comment has been added above the default EVM map noting that every entry must have a corresponding built-in client in NetworkController (see DEFAULT_INFURA_NETWORKS).

References

• Companion mobile PR (full investigation + fix for existing users): MetaMask/metamask-mobile#33379

https://consensyssoftware.atlassian.net/browse/ASSETS-3622

Checklist

• I've updated the test suite for new or updated code as appropriate
• I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
• I've communicated my changes to consumers by updating changelogs for packages I've changed
• I've introduced breaking changes in this PR and have prepared draft pull requests for clients and consumer packages to resolve them

---

Note

Low Risk
Small default-state fix for fresh installs; no auth or payment paths, and Sei remains available via popular networks.

Overview
Removes Sei Mainnet (0x531) from the default enabledNetworkMap in getDefaultNetworkEnablementControllerState so new installs no longer mark Sei as enabled when NetworkController has no built-in client for that chain. That mismatch caused consumers (e.g. mobile lookupEnabledNetworks) to throw in findNetworkClientIdByChainId and fail silently.

Sei is not removed from POPULAR_NETWORKS; users can still add it manually. Persisted enablement for existing profiles is unchanged—only the initial default changes.

A comment on the default EVM map documents that each entry must have a corresponding built-in NetworkController client (DEFAULT_INFURA_NETWORKS). Tests and the package changelog are updated to match.

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

[mcmire]

I feel like it shouldn't be on the maintainers of this controller to manually keep the list of enableable networks up to date with NetworkController. Also, at some point in the future we are going to remove the concept of default / built-in networks from NetworkController — since built-in networks will come from ConfigRegistryController — so this comment will fall out of date when that happens. Plus, we're not calling findNetworkClientIdByChainId here, we're calling that in the clients, so the knowledge that we are referring to is somewhere else, and a maintainer would have to know where to look.

Removing Sei is fine here, but I wonder if we could also add an init method that reads NetworkController state and then automatically removes enabled networks that aren't listed. What do you think about that solution?