feat(wallet): add optional Infura auth token to network controller options

[basgys]

Explanation

NetworkController already accepts getRpcServiceOptions, which customizes the RpcService built for each RPC endpoint, including the fetch it uses. @metamask/wallet forwards nothing to it, so a client has no way to influence RPC requests.

This adds getInfuraAuthToken to the networkController instance options:

const wallet = new Wallet({
  instanceOptions: {
    networkController: {
      infuraProjectId,
      getInfuraAuthToken: () => getBearerToken(),
    },
  },
});

When supplied, the token it returns is presented as Authorization: Bearer on requests to Infura RPC endpoints. Omitting it leaves request behavior unchanged.

Endpoints are matched by hostname. A client configured as NetworkClientType.Infura can still direct traffic elsewhere: getAvailableEndpoints puts failover URLs in the same chain, and under rpcFailoverMode: 'forced' it bypasses Infura entirely. Matching on the client type would hand the credential to a failover provider. create-network-client.ts already checks the hostname for this reason, noting that some networks have been added with invalid configuration types.

The token is read per request. getRpcServiceOptions runs once when the RpcService is constructed, so a value captured there would pin whatever the token was at that moment. Wrapping fetch picks up a refreshed token on the next request.

A token that cannot be retrieved leaves the request unauthenticated. A request that already carries an Authorization header keeps it, since RpcService sets one for endpoints whose URL embeds credentials.

@metamask/wallet now occupies getRpcServiceOptions unconditionally, so a future instance option wanting to customize RPC services has to compose with this function. If the token belongs on the Infura path proper, a first-class option on NetworkController threaded to the Infura branch in create-network-client.ts is the more honest home. That is a two-package change, which is why this starts smaller.

References

None.

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