feat(solana-wallet-snap): add read-only CoreAssetsAdapter and mapControllerAsset

[ulissesferreira]

Explanation

Part of migrating the Solana assets-controller staged migration into this monorepo (PR 3 of 6). Follows the Tron WPN-1497 approach from #144 rather than injecting unused AssetsProvider into AssetsService.

Solana is simpler than Tron: there are no snap-owned assets (no staking/energy/bandwidth equivalents, and NFTs are not Snap-managed). That means Core does not need address monitoring, fetch of snap-owned balances, or keyring-event publishing.

• Add Core messenger plumbing (endowment:messenger, types/core-messenger.ts, AssetsProvider, RemoteFeatureFlagsProvider)
• Add mapControllerAsset that maps controller metadata/balances only. It does not derive associated token account (ATA) pubkeys via findAssociatedTokenPda — Core does not store ATAs, Send already computes them with the correct token program (including Token-2022), and hardcoded TOKEN_PROGRAM_ADDRESS would be wrong for Token-2022
• TokenAsset.pubkey is optional: present on Snap-fetched RPC token accounts, omitted on Core-mapped assets
• Add a read-only CoreAssetsAdapter (AssetsController reads only). No fetch / saveMany / isSnapOwnedAsset NFT path
• Wire CoreAssetsAdapter in snapContext and store it on AssetsService unused (eslint-ignored reserved slot)
• Runtime behavior remains Snap-only — AssetsService stays a thin facade over SnapAssetsAdapter

References

• Jira: WPN-1652
• Stacks on: refactor(solana-wallet-snap): extract SnapAssetsAdapter from existing AssetsService #121
• Tron parallel: feat(tron-wallet-snap): add CoreAssetsAdapter and mapControllerAsset #144
• Next: feature-flag if routing through Core (#123)

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 with latest main and then make sure the CI is green

[cursor]

Rebased ulissesferreira/wpn-1652-core-assets-adapter-6620 onto latest main and got CI green. The already-merged SnapAssetsAdapter commit from #121 was dropped; remaining conflicts were in package.json / yarn.lock.

After rebase, CoreAssetsAdapter still used the old createPrefixedLogger API. I switched it to the shared Logger.withPrefix pattern and inject logger like SnapAssetsAdapter. I also tightened optional-pubkey handling in TransactionsService and synced the Solana snap shasum to the CI-computed value (JetxOe5cWBZ03uo5GFA7mQYSkZwfNw73U7LX/BsOrVI=).

Main CI is green — lint, build, and all package tests passed. The PR is mergeable; BLOCKED is from review/stack requirements, not failing checks.

  

[ulissesferreira]

@cursoragent this PR is almost perfect but we are missing an essential part, pubkey cannot be optional for Transaction History not to break when we migrate to the AssetsController. This means we need some extra logic on the Core Adapter so that when we are reading assets from Core we still have a way to fetch transaction history and we will probably have to get the ATAs for the assets to then fetch history.

[cursor]

TokenAsset.pubkey is required again. When Core maps SPL balances, CoreAssetsAdapter now derives the associated token account so Transaction History can still call getSignaturesForAddress.

It fetches the mint (cached) and uses that mint’s token program with findAssociatedTokenPda, so Token-2022 ATAs are correct and a hardcoded TOKEN_PROGRAM_ADDRESS is not. Native SOL is unchanged. If ATA derivation fails, that token is omitted rather than returned without a pubkey.

Main CI is green on #122 (lint, build, and Solana package tests).