fix(AssetController): refactor Snap data source

[Kriys94]

Explanation

This PR simplifies and cleans up SnapDataSource by:

1. Dynamic snap discovery via PermissionController: Instead of hardcoded snap registry entries, SnapDataSource now dynamically discovers installed snaps that have the endowment:keyring permission and extracts their supported chain IDs from permission caveats. This makes the data source more flexible and extensible for future snaps.

2. Simplified fetch routing: Changed from complex chain-based routing to account-based routing using account.metadata.snap.id. This aligns with how MultichainBalancesController handles snap accounts and is more direct since each account already knows which snap it belongs to.

3. Added KeyringClient: Replaced manual SnapController:handleRequest calls with KeyringClient from @metamask/keyring-snap-client, which provides cleaner typed methods (listAccountAssets, getAccountBalances). This follows the same pattern used in MultichainBalancesController.

4. Removed unused/redundant code:

   • Removed DEFAULT_SNAP_POLL_INTERVAL constant (never used)
   • Removed #groupChainsBySnapId method (no longer needed with account-based routing)
   • Removed #fetchFromSnapById method (inlined into fetch)
   • Removed #accountSupportsChain method (unused after simplification)
   • Removed redundant chain filtering in fetch (already done by middleware/subscribe callers)
   • Removed unused InternalAccount import

5. Used proper types: Replaced inline type Record<string, { amount: string; unit: string }> with GetAccountBalancesResponse and Balance from @metamask/keyring-api.

Dependencies added:

• @metamask/keyring-api: For Balance and CaipAssetType types
• @metamask/keyring-snap-client: For KeyringClient to make typed snap calls

References

• Related to the SnapDataSource dynamic snap discovery refactoring
• Pattern aligned with MultichainBalancesController and MultichainAssetsController implementations

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

High Risk
High risk because it changes SnapDataSource discovery/routing behavior and removes the snapProvider dependency and many exported constants/types, which may break consumers and alter which chains/accounts get queried for balances.

Overview
Refactors SnapDataSource to use dynamic snap discovery instead of a hardcoded Solana/Bitcoin/Tron registry: it now queries SnapController:getRunnableSnaps and PermissionController:getPermissions to build a chainToSnap map from the endowment:assets chainIds caveat, and keeps activeChains empty until discovery succeeds (re-running on PermissionController:stateChange).

Simplifies balance fetching to be account-driven by using account.metadata.snap.id and calling snap keyring methods via KeyringClient (@metamask/keyring-snap-client) over SnapController:handleRequest, plus updates event filtering and cleanup/unsubscribe logic accordingly.

Updates initialization to delegate the new Snap/Permission controller actions/events, removes snapProvider from initDataSources options/tests, trims Snap exports from index.ts, and adds new dependencies/tsconfig references for permission/keyring snap support.

^{Written by Cursor Bugbot for commit 0376a35. This will update automatically on new commits. Configure here.}

[FrederikBolding]

I don't fully understand how this is supposed to work. What if the chainToSnap mapping isn't already populated? Are the inputs BIP-44 account groups or individual accounts?

[Kriys94]

chainToSnap is populated at the initialization of MetaMask, much before that we are fetching assets. So What if the chainToSnap mapping isn't already populated? is unlikely to say impossible.

Are the inputs BIP-44 account groups or individual accounts?
request.accounts is the selected account group

[Prithpal-Sooriya]

Approving on first pass. This data source is completely new and not in production (we have time to refine).

Lets have the snaps team to review before merging. Maybe a short loom/recording to walkthrough changes?

[FrederikBolding]

Not necessarily Snaps-related, but I think you should loop in @mcmire to look at the DataSource architecture. We should ensure that this pattern is aligned with the approach we generally want for data services.

[mcmire]

@FrederikBolding: Thanks for the mention, @Kriys94 messaged me privately about the DataSource code in AssetsController code. I'm looking through it now to understand how it all fits together. @Kriys94: I'll let you know when I have something to share.

[Kriys94]

I have a diagram about what we are trying to build https://consensyssoftware.atlassian.net/wiki/spaces/PRDC/pages/400284352527/Architecture+proposal+34+AssetsController+the+cross-network-asset-type+controller#High-Level-Architecture

Here we call "data source" a piece of logic that extends the AssetsController and implements a specific interface to work with external services (Backend REST APIs, Snap, RPC). The code is related to the business logic, here assets balance, price and metadata.

For @mcmire and this ticket https://consensyssoftware.atlassian.net/browse/WPC-26, I think it refers more to a new service/client I just implemented in core-backend https://github.com/MetaMask/core/tree/main/packages/core-backend#http-api . The code in core-backend is agnostic form business logic.

[Kriys94]

In any case, feel free to comment on the overall code :) It's not released yet so making a braking change is easy :)

[FrederikBolding]

Nice!

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.