feat(aztec.js): plumb immutablesHash through AccountManager.create

[Thunkar]

Summary

Adds an optional AccountManagerCreateOptions argument to AccountManager.create so callers can commit an immutablesHash (and override deployer / publicKeys) without bypassing the standard account-setup pipeline.

export interface AccountManagerCreateOptions {
  immutablesHash?: Fr;
  deployer?: AztecAddress;
  publicKeys?: PublicKeys;
}

static async create(
  wallet: Wallet,
  secretKey: Fr,
  accountContract: AccountContract,
  salt?: Salt,
  opts?: AccountManagerCreateOptions,
): Promise<AccountManager>

getContractInstanceFromInstantiationParams already accepts immutablesHash and deployer, so this is pure plumbing — no protocol-level changes.

Motivation

Enables third-party wallets (e.g. @aztec-kit/embedded-wallet) to set up AZIP-9 initializerless accounts that bind their signing key via ContractInstance.immutables_hash through the normal AccountManager.create path, instead of constructing the instance themselves and reaching for the package-private positional constructor.

Address derivation that includes immutables_hash was landed in #23151 (part 2 of AZIP-9). publish_for_public_execution already forwards immutablesHash from the instance — this PR closes the remaining gap on the account-creation side.

Backwards compatibility

Existing callers that don't pass opts keep producing instances with immutablesHash = Fr.ZERO, matching today's behavior. The fourth-arg salt?: Salt stays in place, so positional callers (incl. cli-wallet, end-to-end, EmbeddedWallet) are unaffected.

Test plan

• New yarn-project/aztec.js/src/wallet/account_manager.test.ts covers:
  • default immutablesHash = Fr.ZERO when no opts are passed
  • a non-zero immutablesHash flows into the resulting instance and address
  • changing immutablesHash changes the derived address