feat: add miden-genesis tool for canonical genesis state

[mmagician]

Summary

• Adds a new miden-genesis binary crate that generates canonical AggLayer genesis accounts and a genesis.toml config file
• Generates three accounts: bridge admin & GER manager (BasicWallets), and AggLayerBridge
• Only the bridge account (nonce=1) is included in genesis.toml for the genesis block; bridge admin and GER manager are local accounts (nonce=0) to be deployed later via transactions. But, they are "implicitly" included in the genesis block in that the AggLayerBridge account makes reference to them in its storage.

Closes #1788

Operator workflow

# Generate canonical genesis accounts
miden-genesis --output-dir ./genesis

# Bootstrap the node
miden-node validator bootstrap \
  --genesis-block-directory ./data \
  --accounts-directory ./accounts \
  --genesis-config-file ./genesis/genesis.toml \
  --validator.key.hex <key>

🤖 Generated by hand & with Claude Code

---

I wanted to add this as a separate minimal binary (non-publishable) because I do see this as a separate role from the validator (even though for now they'll be run by the same entity). But it should be trivial to move this in a new command on the validator if desired.

[mmagician]

While reviewing #1774, I came to realize that there is a split between what the miden-genesis tool would generate (agglayer accounts) vs. what the validator bootstrap would generate (native faucet, plus wallet accounts specified in the TOML).

I think eventually it might make sense to merge these two so that all account generation happens in a single step. The proposed split:

• validator genesis - generates ALL accounts (native faucet, TOML-defined wallets/faucets, AggLayer bridge/admin/GER manager), builds the unsigned genesis block, writes genesis.dat + .mac secret files to an output directory. Takes the validator's public key to embed in the header, making the output deterministic and verifiable by anyone with the same config.
• validator bootstrap - takes the unsigned genesis.dat, signs it with the validator's secret key, and initializes the validator DB (chain tip) (@sergerad 's PR Validator chain invariants #1774)
• store bootstrap - stays as-is

This way genesis is purely about preparing the genesis state (accounts + unsigned block), and bootstrap is about signing and initializing node state. Anyone can run genesis with the same config and verify they obtain the same genesis block, which is desirable.

[Mirko-von-Leipzig]

Code looks good; some bikeshedding to resolve.

[Mirko-von-Leipzig]

If this is intended for internal use only, why do we have two different "modes"?

[Mirko-von-Leipzig]

If this is intended for internal use only, then I would add that disclaimer here, and repeat it where applicable.

I'm concerned that local node users will attempt to use this.

[Mirko-von-Leipzig]

This is going to get outdated pretty often and we'll forget to update this.

It would be better to keep this in our operator docs.

[Mirko-von-Leipzig]

Could you describe the different deployment flows and where this fits in?

1. Local node
2. Testnet deploy
3. Automated devnet deploy
4. ...

Some bikeshedding

Should this be miden-node make-genesis? Bear in mind that we probably want to access this binary somewhere where we can't (or don't want to) compile code. And therefore this should likely be installable and versionable.

Some thought experiments

Maybe we should have a miden-node genesis subcommand?

# This binary
miden-node genesis generate-accounts ...

# miden-node validator bootstrap
miden-node genesis sign

# miden-node store bootstrap
miden-node genesis bootstrap-store