fix(assets-controller): skip redundant Accounts API refetch when WebSocket already confirmed the transaction

[juanmigdr]

Explanation

AssetsController runs a forced Accounts API balance refetch every time a transaction is confirmed, even when AccountActivityService's WebSocket already delivered the same balance update for that chain. That's an unnecessary HTTP call whenever the WebSocket connection is healthy.

This change makes AssetsController check whether the transaction's chain is WS-active, and if so, wait briefly for a matching AccountActivityService:transactionUpdated event (correlated by transaction hash) before forcing the API refetch. If the WebSocket confirms in time, the API call is skipped; if it doesn't (WS down, message dropped, etc.), the API call still happens as a fallback, so behavior is unchanged when the WebSocket isn't available.

One thing worth calling out for reviewers: transactionConfirmed and the WebSocket's transactionUpdated push are two independent signals that can arrive in either order — the WebSocket message frequently arrives before transactionConfirmed fires. The implementation accounts for this by tracking whichever one arrives first per transaction, so it works correctly regardless of ordering.

Breaking change: AssetsController now subscribes to AccountActivityService:transactionUpdated. Any host that restricts which events flow through the AssetsController messenger (e.g. via a scoped delegation list) must add this event, or AssetsController will never see it and will always fall back to the API call.

References

• Mobile client adoption: chore(assets-controller): delegate AccountActivityService:transactionUpdated for v15 metamask-mobile#35202
• Extension client adoption: chore(assets-controller): delegate AccountActivityService:transactionUpdated for v15 metamask-extension#45718
• Ticket: https://consensyssoftware.atlassian.net/browse/ASSETS-3910 & https://consensyssoftware.atlassian.net/browse/ASSETS-3916

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

Medium Risk
Changes post-confirmation balance refresh timing and adds a breaking messenger subscription; stale balances are possible only if WS falsely signals confirmation and the API fallback is skipped, but timeout fallback preserves prior behavior when WS is unreliable.

Overview
After a transaction confirms, AssetsController no longer always forces an Accounts API balance refetch. When the chain is WebSocket-active and the confirmation includes a hash, it waits up to 1.5s for a matching AccountActivityService:transactionUpdated event; if that arrives first (including when WS fires before transactionConfirmed), the HTTP refetch is skipped.

If the chain is not WS-active, the hash is missing, or the WS signal never matches in time, behavior is unchanged: getAssets still runs with forceUpdate: true. Coordination uses a per-transaction map with cleanup on destroy.

Breaking: the controller now subscribes to AccountActivityService:transactionUpdated; hosts that scope messenger events must delegate it or the optimization never applies.

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