feat: update provider type

[hmalik88]

• What is the current state of things and why does it need to change? There should be an easy way to identify the type of provider. Account discovery isn't limited to one group index, the discovery method should be looping through indices and provide said index to createAccounts
• What is the solution your changes offer and how does it work? Add providerType property, add AccountProviderType enum and remove groupIndex from discoverAndCreateAccounts.

Feature: Account Provider Type Management
  As a MetaMask developer
  I want to properly identify and manage different account provider types
  So that account discovery can work efficiently across multiple blockchain networks

  Background:
    Given the MetaMask accounts system is initialized
    And the AccountProviderType enum is available

  @provider-type @enum
  Scenario: AccountProviderType enum contains all supported provider types
    Given the AccountProviderType enum is defined
    When I check the available provider types
    Then I should see the following provider types:
      | Provider Type |
      | Evm          |
      | Solana       |
      | Btc          |
    And each provider type should be a valid enum value
    And no additional provider types should be present

  @provider-type @validation
  Scenario: Provider type property accepts only valid AccountProviderType values
    Given I have an account provider instance
    When I set the providerType to "Evm"
    Then the providerType should be set to AccountProviderType.Evm
    And the provider should be valid

  @provider-type @validation @error-handling
  Scenario: Provider type property rejects invalid values
    Given I have an account provider instance
    When I attempt to set the providerType to an invalid value "InvalidType"
    Then the system should reject the invalid provider type
    And an appropriate error should be thrown
    And the provider should remain in a valid state

  @provider-type @evm
  Scenario: EVM provider has correct provider type
    Given I create an EVM account provider
    When I check the provider type
    Then the providerType should be AccountProviderType.Evm
    And the provider should support EVM-specific operations
    And the provider should be identifiable as an EVM provider

  @provider-type @solana
  Scenario: Solana provider has correct provider type
    Given I create a Solana account provider
    When I check the provider type
    Then the providerType should be AccountProviderType.Solana
    And the provider should support Solana-specific operations
    And the provider should be identifiable as a Solana provider

  @provider-type @btc @future-proofing
  Scenario: BTC provider type is available for future implementation
    Given the AccountProviderType enum includes Btc
    When I reference AccountProviderType.Btc
    Then the Btc provider type should be available
    And it should be ready for future BTC provider implementation
    And it should not cause any runtime errors

  @account-discovery @provider-identification
  Scenario: Account discovery can identify provider types during discovery
    Given I have multiple account providers:
      | Provider Type | Status    |
      | Evm          | Active    |
      | Solana       | Active    |
      | Btc          | Inactive  |
    When I perform account discovery
    Then the discovery process should identify each provider by its type
    And EVM accounts should be discovered using the Evm provider
    And Solana accounts should be discovered using the Solana provider
    And BTC provider should be skipped if inactive

  @account-discovery @group-index-removal
  Scenario: Account discovery works without groupIndex requirement
    Given I have an account provider with providerType set
    And the discoverAndCreateAccounts method is available
    When I call discoverAndCreateAccounts without providing groupIndex
    Then the method should execute successfully
    And accounts should be discovered across multiple indices
    And no groupIndex parameter should be required

  @account-discovery @multiple-indices
  Scenario: Account discovery loops through multiple indices
    Given I have an EVM account provider
    And there are accounts at indices 0, 1, and 2
    When I call discoverAndCreateAccounts
    Then the discovery should check index 0
    And the discovery should check index 1
    And the discovery should check index 2
    And all discovered accounts should be created
    And the discovery should continue until no more accounts are found

  @provider-type @service-integration
  Scenario: Service can use providerType for skipped providers functionality
    Given I have a discovery service
    And I have multiple providers with different types:
      | Provider Type | Should Skip |
      | Evm          | false       |
      | Solana       | true        |
      | Btc          | true        |
    When I configure skippedProviders to include ["Solana", "Btc"]
    And I perform account discovery
    Then only the Evm provider should be used for discovery
    And Solana provider should be skipped
    And Btc provider should be skipped
    And the service should identify providers by their providerType

  @provider-type @type-safety
  Scenario: Provider type ensures type safety at compile time
    Given I have TypeScript compilation enabled
    When I assign a valid AccountProviderType to providerType
    Then the code should compile without errors
    And type checking should pass
    And IntelliSense should provide proper autocomplete

  @provider-type @type-safety @error-handling
  Scenario: Invalid provider type causes compile-time error
    Given I have TypeScript compilation enabled
    When I attempt to assign an invalid string to providerType
    Then TypeScript should show a compilation error
    And the error should indicate the expected AccountProviderType values
    And the code should not compile until fixed

  @provider-type @backwards-compatibility
  Scenario: Provider type change maintains API compatibility
    Given existing code that uses account providers
    When the providerType property is accessed
    Then the property should return an AccountProviderType value
    And existing functionality should continue to work
    And no breaking changes should be introduced to public APIs

  @account-discovery @performance
  Scenario: Account discovery performs efficiently without groupIndex constraint
    Given I have providers for multiple blockchain types
    And each provider has accounts at various indices
    When I perform account discovery across all providers
    Then the discovery should complete within acceptable time limits
    And memory usage should remain within reasonable bounds
    And the discovery should not cause performance degradation

  @provider-type @integration
  Scenario: Multiple providers can coexist with different types
    Given I have the following providers configured:
      | Provider Type | Instance Name    |
      | Evm          | EthereumProvider |
      | Solana       | SolanaProvider   |
    When I access each provider's type
    Then EthereumProvider.providerType should be AccountProviderType.Evm
    And SolanaProvider.providerType should be AccountProviderType.Solana
    And both providers should function independently
    And provider types should not conflict with each other

  @account-discovery @error-handling
  Scenario: Account discovery handles provider errors gracefully
    Given I have multiple account providers
    And one provider throws an error during discovery
    When I perform account discovery
    Then the discovery should continue with other providers
    And the error should be logged appropriately
    And successful providers should still create accounts
    And the overall discovery process should not fail completely

  @provider-type @documentation
  Scenario: Provider type enum is properly documented
    Given the AccountProviderType enum is defined
    When I check the JSDoc documentation
    Then each enum value should have clear documentation
    And the purpose of each provider type should be explained
    And usage examples should be provided where appropriate
    And the documentation should be up to date with the implementation

[hmalik88]

@metamaskbot publish-preview

[github-actions]

Preview builds have been published. See these instructions (from the core monorepo) for more information about preview builds.

Expand for full list of packages and versions.

{
  "@metamask-previews/account-api": "0.9.0-2c74956",
  "@metamask-previews/keyring-api": "20.0.0-2c74956",
  "@metamask-previews/eth-hd-keyring": "12.1.0-2c74956",
  "@metamask-previews/eth-ledger-bridge-keyring": "11.1.2-2c74956",
  "@metamask-previews/eth-simple-keyring": "10.0.0-2c74956",
  "@metamask-previews/eth-trezor-keyring": "9.0.0-2c74956",
  "@metamask-previews/keyring-internal-api": "8.0.0-2c74956",
  "@metamask-previews/keyring-internal-snap-client": "6.0.0-2c74956",
  "@metamask-previews/eth-snap-keyring": "16.0.0-2c74956",
  "@metamask-previews/keyring-snap-client": "7.0.0-2c74956",
  "@metamask-previews/keyring-snap-sdk": "6.0.0-2c74956",
  "@metamask-previews/keyring-utils": "3.1.0-2c74956"
}