fix(multichain-account-service)!: wait for Snap platform to be ready

[ccharly]

Explanation

Snap requests are now delayed after the onboarding, to avoid starting requests "too soon" on the clients, we now have a logic to wait for the Snap platform to be ready.

This makes sure that any calls that uses retries or timeouts will start their calls AFTER the Snap platform is ready to process anything.

We stumbled upon this bug during the concurrent requests/Snap state inconsistency investigation. Initial account providers requests were usually timing out because they were hitting their limit because they were starting a bit "late" since the Snap platform was not ready yet. (This was also still causing concurrent requests, despite the maxConcurrency: 1, since Snaps were still processing the timed out request while receiving new ones).

To future-proof this and fully await for the Snap platform to be ready, we now send 1 simple Snap request and wait for it to be executed (being successful or not). Then, we start processing all Snap requests with our usual logic (timeouts, semaphore, retries, etc...)

References

• TimeoutError: Timed out metamask-mobile#23807

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

Waits for the Snap platform to be ready before any provider operations, renaming abstract create/discover methods to run* and updating providers/tests accordingly.

• Core (SnapAccountProvider)
  • Add ensureSnapPlatformIsReady (singleton promise) and call it in constructor and before createAccounts, discoverAccounts, resyncAccounts, and Snap keyring access.
  • Implement readiness ping via KeyringRpcMethod.GetAccount/ListAccounts through KeyringClient.
  • Base now implements createAccounts/discoverAccounts to await readiness, delegating to new abstract runCreateAccounts/runDiscoverAccounts.
  • Add helper BaseBip44AccountProvider.getAnyAccount() to support fast ping selection.
• Providers
  • Update SolAccountProvider, BtcAccountProvider, TrxAccountProvider to use runCreateAccounts/runDiscoverAccounts (renamed from createAccounts/discoverAccounts).
• Tests
  • Introduce mock providers overriding readiness wait; add tests for platform readiness behavior; update existing tests to new method names and messaging mocks.
• Changelog
  • Document added Snap readiness wait and BREAKING rename of abstract methods.

^{Written by Cursor Bugbot for commit 0ccef45. This will update automatically on new commits. Configure here.}

[ccharly]

Mainly using a protected static here so we can write tests and update this without exposing it completely publicly (consumers could still hack this easily though..)

[ccharly]

Question: Should we have a 1 promise per Snap? This would allow to wait for the Snap to be ready rather than the Snap platform itself?

[hmalik88]

Wouldn't the snap be ready if the platform is?

[ccharly]

I guess so yes, so I think we can keep this as-is!

[ccharly]

Now providers have to implements those run* methods, so we can automatically call this.ensureSnapPlatformIsReady for any of those actions.