refactor(snap-solana-wallet): align Solana AssetsService read API with snap-networks-utils

[ulissesferreira]

Explanation

Part of migrating the Solana assets-controller staged migration from snap-solana-wallet#635 into this monorepo (PR 1 of 6, Lane A / feature-flag path only).

• Add shared read API methods on AssetsService: getAccountAssetByID, getAccountAssetsByIDs, getAccountAssetsByScope, getAccountAssets
• Wire accountsService into AssetsService (needed for account lookup by ID)
• Update Keyring and Send to use the new API
• No behavior change — still reads from Snap-owned assetEntities via AssetsRepository
• Rebased onto latest main (includes chore(solana-wallet-snap): deprecate pre-Unified Send Flow code #130 removal of legacy send UI / refreshSend cron — those paths are no longer updated here)

Read API surface

Migration call sites use only these four methods, with return shapes aligned to AssetsProvider / AssetsController patterns (single element, map-by-ID, scoped array, full array):

Method	Return type
getAccountAssetByID	AssetEntity | null
getAccountAssetsByIDs	Record<string, AssetEntity | null>
getAccountAssetsByScope	AssetEntity[]
getAccountAssets	AssetEntity[]

CI babysit fixes

• Fix unused-vars eslint failures in SendService and prune the stale suppression
• Rebased onto latest main (Release/6.0.0 + chore(solana-wallet-snap): deprecate pre-Unified Send Flow code #130 send-flow deprecation)
• Synced snap.manifest.json shasum with the CI production build after rebase

References

• Migrated from: chore(WPN-1652): align Solana AssetsService read API with snap-networks-utils snap-solana-wallet#635
• Jira: WPN-1652
• Tron parallel: handler/read API alignment (see #90)
• Next: WPN-1652-snap-assets-adapter (extract SnapAssetsAdapter)

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

  

[ulissesferreira]

@cursoragent rebase latest main and make sure the CI is green

[cursor]

Taking a look!

  

[ulissesferreira]

@cursoragent in this migration make sure the calls to the AssetsService are all one of the following method names:

getAccountAssetByID, getAccountAssetsByIDs, getAccountAssetsByScope, getAccountAssets

where the return types follow a similar logic to the AssetsProvider first 3 methods. Not the same return type, but similar takes on single element, map, array and array

[cursor]

Aligned the migration with the four-method read API you specified.

Changes

1. Added getAccountAssets to AssetsService — returns AssetEntity[] across all active networks (replaces the inlined getAccountAssetsByScope loop in Keyring).

2. Updated Keyring.getAccountAssets — now calls this.#assetsService.getAccountAssets(accountId) instead of fanning out per scope.

3. Read API surface — migration call sites now use only these four methods with return shapes matching AssetsProvider patterns:

Method	Return type	Used by
getAccountAssetByID	AssetEntity | null	(service layer)
getAccountAssetsByIDs	Record<string, AssetEntity | null>	Keyring balances, Send
getAccountAssetsByScope	AssetEntity[]	(service layer)
getAccountAssets	AssetEntity[]	Keyring asset listing

4. Tests updated — AssetsService.test.ts, Keyring.test.ts; all 95 tests in the affected suites pass.

The previous getAccountAssetsForAllActiveScopes name is gone; getAccountAssets is the canonical fourth method, consistent with the Tron snap pattern.

  

[gabrieledm]

This, in the future, will probably be removed in favour of a setup function