perf(multichain-account-service): add Solana account batching

[ccharly]

Explanation

Implementing proper batching for our Solana account provider.

References

• perf(multichain-account-service): add :createMultichainAccountGroups action to batch account creation  #7801
• perf(account-tree-controller): use batched account creation in backup & sync #7907

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 Solana account creation to use a new batch Snap keyring API and adjusts how BIP-44 entropy metadata is synthesized, which could impact account derivation/indexing and timeouts if the Snap/keyring behavior differs from expectations.

Overview
Solana account creation is now batched. SolAccountProvider.createAccounts switches from per-account createAccount calls (looping for ranges) to a single SnapKeyring.createAccounts call for both single-index and range creation, reducing keyring locking/API overhead.

To support this, SnapAccountProvider’s restricted keyring surface now exposes createAccounts, and the Solana provider maps returned Snap accounts to BIP-44 accounts by injecting entropy/derivationPath based on the requested indices before asserting compatibility and tracking created IDs.

Tests and mocks were updated to expect the batch API (and not the singular call), and a small helper toGroupIndexRangeArray was added for range-based test keyring behavior; changelog updated to note the optimization.

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

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

[cursor]

Undefined range.from causes NaN group indices

High Severity

groupIndexOffset = options.range.from doesn't handle the optional from field. The GroupIndexRange type defines from as from?: number, so when omitted, groupIndexOffset becomes undefined. This causes groupIndexOffset + index to evaluate to NaN, producing invalid derivation paths like m/44'/501'/NaN'/0' and incorrect groupIndex values in the entropy metadata. A nullish coalescing default like ?? 0 is needed, consistent with how from is handled elsewhere (e.g., toGroupIndexRangeArray and assertGroupIndexRangeIsValid both default from to 0).

Additional Locations (1)

• packages/multichain-account-service/src/providers/SolAccountProvider.ts#L144-L146

 

[ccharly]

This range.from comes from the keyring API, it cannot be undefined (at least, type-wise, we do not expect it to be undefined)