…dleware` (#6623)

## Explanation

This PR integrates the `auxiliaryFunds` and `requiredAssets`
capabilities defined under
[ERC-7682](https://eips.ethereum.org/EIPS/eip-7682) to enable auxiliary
funds flows and improve capability consistency across clients.

<!--
Thanks for your contribution! Take a moment to answer these questions so
that reviewers have the information they need to properly understand
your changes:

* What is the current state of things and why does it need to change?
* What is the solution your changes offer and how does it work?
* Are there any changes whose purpose might not obvious to those
unfamiliar with the domain?
* If your primary goal was to update one package but you found you had
to update another one along the way, why did you do so?
* If you had to upgrade a dependency, why did you do so?
-->

## References

<!--
Are there any issues that this pull request is tied to?
Are there other links that reviewers should consult to understand these
changes better?
Are there client or consumer pull requests to adopt any breaking
changes?

For example:

* Fixes #12345
* Related to #67890
-->

* Fixes https://consensyssoftware.atlassian.net/browse/WAPI-409

## Checklist

- [x] I've updated the test suite for new or updated code as appropriate
- [x] I've updated documentation (JSDoc, Markdown, etc.) for new or
updated code as appropriate
- [x] I've communicated my changes to consumers by [updating changelogs
for packages I've
changed](https://github.com/MetaMask/core/tree/main/docs/contributing.md#updating-changelogs),
highlighting breaking changes as necessary
- [x] I've prepared draft pull requests for clients and consumer
packages to resolve any breaking changes

Minor releases of both the `account-tree-controller` and
`multichain-account-services` which includes:
- Solana discovery timeout and retry mechanism
- Custom account provider configurations
- Prevent single backup & sync enqueues during full-sync
- Prevent temporary EVM account creation during EVM discovery

…onous (#6656)

## Explanation

The method `decodePermissionFromPermissionContextForOrigin` was
incorrectly implemented as a synchronous function. This change updates
this function and related tests to be synchronous.

Because this function has not yet been released, this is not being
considered a breaking change.

## Checklist

- [x] I've updated the test suite for new or updated code as appropriate
- [x] 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](https://github.com/MetaMask/core/tree/main/docs/contributing.md#updating-changelogs),
highlighting breaking changes as necessary
- [ ] I've prepared draft pull requests for clients and consumer
packages to resolve any breaking changes

Releases @metamask/gator-permissions-controller@0.2.0

## Explanation

Release for `@metamask/eip-5792-middleware`
- Add `auxiliaryFunds` + `requiredAssets` support defined under
[ERC-7682](https://eips.ethereum.org/EIPS/eip-7682)
([#6623](#6623))
- Bump `@metamask/transaction-controller` from `^60.2.0` to `^60.4.0`
([#6561](#6561),
[#6641](#6641))
- Bump `@metamask/utils` from `^11.4.2` to `^11.8.0`
([#6588](#6588))

<!--
Thanks for your contribution! Take a moment to answer these questions so
that reviewers have the information they need to properly understand
your changes:

* What is the current state of things and why does it need to change?
* What is the solution your changes offer and how does it work?
* Are there any changes whose purpose might not obvious to those
unfamiliar with the domain?
* If your primary goal was to update one package but you found you had
to update another one along the way, why did you do so?
* If you had to upgrade a dependency, why did you do so?
-->

## References

<!--
Are there any issues that this pull request is tied to?
Are there other links that reviewers should consult to understand these
changes better?
Are there client or consumer pull requests to adopt any breaking
changes?

For example:

* Fixes #12345
* Related to #67890
-->

* Fixes https://consensyssoftware.atlassian.net/browse/WAPI-409

## 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](https://github.com/MetaMask/core/tree/main/docs/contributing.md#updating-changelogs),
highlighting breaking changes as necessary
- [ ] I've prepared draft pull requests for clients and consumer
packages to resolve any breaking changes

## Explanation

fix init function. , every new network added to the conf should not
change the users config

<!--
Thanks for your contribution! Take a moment to answer these questions so
that reviewers have the information they need to properly understand
your changes:

* What is the current state of things and why does it need to change?
* What is the solution your changes offer and how does it work?
* Are there any changes whose purpose might not obvious to those
unfamiliar with the domain?
* If your primary goal was to update one package but you found you had
to update another one along the way, why did you do so?
* If you had to upgrade a dependency, why did you do so?
-->

## References

<!--
Are there any issues that this pull request is tied to?
Are there other links that reviewers should consult to understand these
changes better?
Are there client or consumer pull requests to adopt any breaking
changes?

For example:

* Fixes #12345
* Related to #67890
-->

## 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](https://github.com/MetaMask/core/tree/main/docs/contributing.md#updating-changelogs),
highlighting breaking changes as necessary
- [ ] I've prepared draft pull requests for clients and consumer
packages to resolve any breaking changes

…6660)

## Explanation

Add missing exports that needs to be used for the `providerConfigs`.

## 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](https://github.com/MetaMask/core/tree/main/docs/contributing.md#updating-changelogs),
highlighting breaking changes as necessary
- [ ] I've prepared draft pull requests for clients and consumer
packages to resolve any breaking changes

---------

Co-authored-by: Mathieu Artu <mathieu.artu@consensys.net>

## Explanation

<!--
Thanks for your contribution! Take a moment to answer these questions so
that reviewers have the information they need to properly understand
your changes:

* What is the current state of things and why does it need to change?
* What is the solution your changes offer and how does it work?
* Are there any changes whose purpose might not obvious to those
unfamiliar with the domain?
* If your primary goal was to update one package but you found you had
to update another one along the way, why did you do so?
* If you had to upgrade a dependency, why did you do so?
-->

## References

<!--
Are there any issues that this pull request is tied to?
Are there other links that reviewers should consult to understand these
changes better?
Are there client or consumer pull requests to adopt any breaking
changes?

For example:

* Fixes #12345
* Related to #67890
-->

## 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](https://github.com/MetaMask/core/tree/main/docs/contributing.md#updating-changelogs),
highlighting breaking changes as necessary
- [ ] I've prepared draft pull requests for clients and consumer
packages to resolve any breaking changes

)

## Explanation

**CRITICAL FIX**: Resolves a severe multi-wallet account naming bug that
caused duplicate, inconsistent, and confusing account group names across
different seed phrases (SRPs).

### Current Problem
Users importing multiple seed phrases experienced catastrophic naming
issues:
- **Duplicate names**: Multiple "Account 2", "Account 3" within the same
wallet
- **Missing "Account 1"**: Some wallets would start at "Account 2" 
- **Cross-wallet confusion**: Second SRP incorrectly showing "Account 3"
when it should be "Account 1"
- **Inconsistent after restart**: Names would change unpredictably on
app restart

### Root Cause
The account group naming logic had critical flaws:

1. **Broken alphabetical sorting**: Used
`Object.keys(wallet.groups).sort()` which caused conflicts and
duplicates in multi-wallet scenarios
2. **Unsafe entropy access**: Could throw TypeError when accessing
`group.metadata.entropy.groupIndex` without null checks
3. **Negative index bug**: Empty wallets would get `-1` index, causing
invalid "Account 0" names

### Solution
Implemented a robust fix with comprehensive improvements:

1. **Per-wallet sequential numbering**: Each wallet maintains
independent "Account 1", "Account 2", etc. numbering with dynamic
pattern detection that works with any naming convention ("Account N",
"Imported Account N", etc.)
2. **Smart conflict resolution**: Universal conflict detection with
`while` loop that finds next available unique name, handles user
renames, and ensures unique sequential names
3. **Entropy-aware indexing**: For multichain groups, prioritizes actual
`groupIndex` from entropy metadata when available with safe null checks
4. **Starting point optimization**: Begins name checking at
`wallet.groups.length` to minimize iterations and improve efficiency
5. **AutoHandleConflict integration**: Added optional
`autoHandleConflict` parameter to `setAccountGroupName()` for automated
conflict resolution with suffix generation (`"Account 1 (2)"`, `"Account
1 (3)"`, etc.) - ready for Backup & Sync integration

## References

Fixes: 
- [MUL-835](https://consensyssoftware.atlassian.net/browse/MUL-835)
- [MUL-826](https://consensyssoftware.atlassian.net/browse/MUL-826)

## Checklist

- [x] I've updated the test suite for new or updated code as appropriate
- [x] I've updated documentation (JSDoc, Markdown, etc.) for new or
updated code as appropriate
- [x] I've communicated my changes to consumers by updating changelogs
for packages I've changed, highlighting breaking changes as necessary
- [x] I've prepared draft pull requests for clients and consumer
packages to resolve any breaking changes

[MUL-835]:
https://consensyssoftware.atlassian.net/browse/MUL-835?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ

---------

Co-authored-by: Charly Chevalier <charly.chevalier@consensys.net>

Our constraints for `peerDependencies` previously only required the
major version to match. However, this was problematic for pre-1.0
packages because it allowed for situations where we cannot update a
package without introducing a peer dependency error, since pre-1.0
packages can have breaking changes in minor or patch releases.

The constraint has been updated to require the most significant part
of the version to be synchronized for peer dependencies, and all
resulting constraint errors have been auto-fixed.