feat(cli): support funding accounts in validator-keys new/set-funding-account

[aminsammara]

Summary

Wires a real --funding-account option into aztec validator-keys new (previously commented out with a TODO, so operators had to hand-edit the keystore JSON), and adds a dedicated set-funding-account subcommand for existing keystores.

Per review feedback, add does not take --funding-account: the funding account is a keystore-level field (the only one KeystoreManager.createFundingSigner reads), so setting it from add would be a global mutation disguised as a per-validator flag. Use set-funding-account instead:

aztec validator-keys set-funding-account <keystore.json> <privateKey|address> [--remote-signer <url>] [--password <str>]

Behavior

• The funding account value accepts either a 32-byte private key or a 20-byte address.
• An address requires --remote-signer (a local funder needs its private key to sign funding txs); it is stored as { address, remoteSignerUrl }.
• With --password, a plaintext funder key is encrypted to a JSON V3 file and replaced with a { path, password } reference, mirroring how attester/publisher keys are handled.
• The value is written at the keystore top level (keystore.fundingAccount). Validator-level funding exists in the schema but is never consumed at runtime, so it is intentionally not emitted.
• set-funding-account replaces an existing funding account with a warning.

Changes

• index.ts — real --funding-account option on new; new set-funding-account subcommand.
• set_funding_account.ts — new command: validate, resolve, optionally encrypt, write keystore.fundingAccount.
• utils.ts — validateFundingAccountOptions (normalize + validate key/address, require remote-signer for address form).
• shared.ts — resolveFundingAccount and encryptFundingAccountToFile; extracted the ETH JSON V3 encryption helper for reuse.
• new.ts — validate, resolve, optionally encrypt, set keystore.fundingAccount.
• valkeys.test.ts — 17 new tests covering validation, private-key/address/password paths on new, and set/replace on set-funding-account.

Testing

• yarn workspace @aztec/cli test src/cmds/validator_keys/valkeys.test.ts — 60 passed.
• yarn build, yarn format cli, yarn lint cli — all clean.

[aminsammara]

Failing test is a flake that passed on a re-run. Should be good to merge after a review.

[spalladino]

I fear that the behaviour of --funding-account in validator-keys add is confusing. I'd've expected it to add a new key to an existing keystore with the given funding account, not that it would overwrite the keystore single funding account. If that's the behaviour we want, I'd remove --funding-account from add, and just add a new subcommand set-funding-account.

The behaviour in new looks good btw.

Unrelated: why not just build on merge-train/spartan-v5 and let a forward-port to next handle sending it to next?

[aminsammara]

I'd remove --funding-account from add, and just add a new subcommand set-funding-account.

Agreed, and implemented.

why not just build on merge-train/spartan-v5 and let a forward-port to next handle sending it to next?

I didn't know we had automated forward ports. Rebased on top of spartan-v5

[AztecBot]

✅ Successfully backported to backport-to-v5-next-staging #24670.