Release/1020.0.0

[ccharly]

Explanation

• Major release of the accounts-controller to start using the new events from the snap-account-service instead of the SnapKeyring legacy instance
• Minor release of the snap-account-service to publish those events

References

N/A

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
Breaking messenger contract on accounts-controller affects all clients and downstream controllers; incorrect event registration would break snap account balance/asset/transaction updates.

Overview
Monorepo release 1020.0.0 — bumps published package versions, changelogs, package.json dependency ranges, and yarn.lock across the workspace (no new application logic in this diff).

The headline consumer change is @metamask/accounts-controller v39 (breaking): account asset/balance/transaction updates are re-published from SnapAccountService events instead of legacy SnapKeyring events, so messenger wiring must register the Snap Account Service events and can drop SnapKeyring equivalents.

@metamask/snap-account-service v0.3.0 adds the corresponding SnapAccountService:account{AssetList,Balances,Transactions}Updated events; @metamask/multichain-account-service and dependents pick that up via dependency bumps.

Everything else in the release is mostly patch/minor version bumps (e.g. transaction-controller 66.0.1, account-tree-controller 7.5.1, bridge/assets packages) propagating the accounts-controller and snap-account-service updates through the dependency graph.

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

[mm-token-exchange-service]

✅ No changelog changes needed.

[ccharly]

There's a ### Added that adds the keyring-controller dep explicitly. I don't think this really justify bumping the minor (given it was already in-use, just not declared really).

Or do we want to bump the minor instead?