feat(tron): return live data from listAccountAssets and getAccountBalances

[ulissesferreira]

Explanation

listAccountAssets and getAccountBalances in the Tron Snap previously returned whatever was persisted in the Snap's state, so the data was only as fresh as the last cronjob indexation. This is needed so the assets controller can use the Snap as the data source for reconcile when the asset migration feature flag switches back.

Changes:

• getAccountAssets (listAccountAssets) and getAccountBalances now fetch live assets and balances from the chain (via fetchAssetsAndBalancesForAccount) instead of reading persisted state. Fetch failures propagate to the caller.
• getAccountBalances only fetches live data for the scopes the requested assets belong to, avoiding unnecessary chain calls.

References

Ticket: WPN-2217

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

[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

[mikesposito]

Should we relax fetchAccountAssetsByScope's scope argument type to accept ${string}:${string}, or add a type guard here so we don't need this cast?

[ulissesferreira]

Hmm very good idea, as is definitely to be avoided. Let me give it a try.

[ulissesferreira]

The problem is we are using Network everywhere as the required type. So basically, somehow, we need to convert the input on handlers and then have Network internally which is more specific

[mikesposito]

if we want to keep using Network we should add a type guard to narrow down the type from ${string}:${string} so that we throw on unsupported scopes while also making typescript happy - this function seems to be a good place to do it since we take the scope value directly from the KeyringAccount

[ulissesferreira]

100%. I am going to look around the code and see if it makes sense to add some more of that here or open a PR right next to it

[mikesposito]

It should be no more than three lines of code before this Promise.all call, so IMO we can do it in this PR, but your call