[BUG] SchnorrAccount (v5.0.1) bakes in stale v5.0.0 HandshakeRegistry address, breaking private function calls after network upgrade

[pplmaverick]

What are you trying to do?

Deploying a Noir contract + Schnorr account to Aztec Alpha Mainnet via the
aztec-wallet CLI (v5.0.1, matching the network's post-AZUP-2 version), then
calling a private function on that contract from the deployed account. The
private function uses SingleUseClaim (a common pattern for "vote once" /
"claim once" logic), which internally triggers a cross-contract utility call
into the HandshakeRegistry standard contract.

The call fails with:

Error: Cannot call 0x0193c31bd24d0347aa9ed889cd6d304832988625c2f21c411e7af9d703591aa5:0xc475a0eb:
the contract is not registered. Register it via wallet.registerContract(...).

and, after manually registering that old artifact locally:

Cross-contract utility call denied: No authorizeUtilityCall hook configured.
attempted to call 0x0193c31b...:0xc475a0eb (get_non_interactive_handshakes).

Root cause (see Code Reference below): the SchnorrAccount contract bundled
in @aztec/accounts@5.0.1 has the OLD, v5.0.0-vintage HandshakeRegistry
address (0x0193c31b...) baked into its compiled bytecode, instead of the
current v5.0.1 address (0x086c3c67...). This breaks every private call that
touches HandshakeRegistry, for every account created with the 5.0.1 CLI, on
every network actually running v5.0.1 (i.e. live Alpha Mainnet and Testnet
right now).

Code Reference

// Zero-cost repro: no network/funds needed, just compares two npm package
// versions directly.
//
// npm pack @aztec/standard-contracts@5.0.0 && tar xzf aztec-standard-contracts-5.0.0.tgz
// npm pack @aztec/standard-contracts@5.0.1 && tar xzf aztec-standard-contracts-5.0.1.tgz
// grep "HandshakeRegistry:" package/dest/standard_contract_data.js # (in each extracted dir)

// @aztec/standard-contracts@5.0.0 exports:
HandshakeRegistry: AztecAddress.fromStringUnsafe(
'0x0193c31bd24d0347aa9ed889cd6d304832988625c2f21c411e7af9d703591aa5'
)

// @aztec/standard-contracts@5.0.1 exports:
HandshakeRegistry: AztecAddress.fromStringUnsafe(
'0x086c3c67589e1141c70ed0ed8ae324c51d3bf7c5637043fd84c424ffb625831d'
)

// But an account deployed with aztec-wallet CLI 5.0.1's SchnorrAccount
// still calls 0x0193c31b... (the 5.0.0 address) when a private function
// triggers a HandshakeRegistry utility call -- confirmed by tracing the
// simulation error back to SchnorrAccount.entrypoint on a real Alpha
// Mainnet deployment (chain id 1, rollup version 4248422647).

Aztec Version

5.0.1

OS

macOS

Browser (if relevant)

N/A (CLI / aztec.js, not browser-related)

Node Version

24.12.0

Additional Context

Likely introduced by the HandshakeRegistry rework between 5.0.0 and 5.0.1
(e.g. PR #24511 "rename get_handshakes to non_interactive variant", #24062
"add msg_sender to the utility context", #23938, #24473) -- these changed
HandshakeRegistry's bytecode/class id, but @aztec/accounts wasn't
recompiled/regenerated against the new address before the 5.0.1 release.

Workaround we used to unblock our own mainnet deployment:

1. Deploy the OLD (5.0.0) HandshakeRegistry artifact ourselves at its
   deterministic address (permissionless: salt=1, --universal, --no-init),
   so something answers at 0x0193c31b...
2. In aztec.js, explicitly wallet.registerContract(instance, artifact) for
   that same old artifact, and configure a PXE authorizeUtilityCall hook
   authorizing calls to that address.

This is not a real fix, just papers over the mismatch with an orphaned
duplicate deployment. Suggested real fix: recompile/regenerate every account
type in @aztec/accounts (and anywhere else a "standard contract" singleton
address gets embedded) in the same release step as @aztec/standard-contracts,
ideally with a CI check that diffs each account's embedded standard-contract
addresses against the current @aztec/standard-contracts package so this
class of bug can't ship again.