[FEATURE] Warn or block the default test mnemonic when bridging Fee Juice on a real network

[pplmaverick]

Problem Statement

aztec-wallet bridge-fee-juice (and other L1-signing commands that accept
--mnemonic) default to the well-known public Hardhat/Anvil test mnemonic:

"test test test test test test test test test test test junk"

This default applies silently even when --l1-chain-id is set to a real
network -- e.g. 1 for Ethereum mainnet. There is no warning, confirmation
prompt, or guard rail of any kind. Anyone who forgets to pass an explicit
--l1-private-key (or their own --mnemonic) when bridging on mainnet gets
no signal from the tool that it just derived a signer from publicly known,
zero-security credentials -- the command just runs.

We hit this ourselves while bridging real $AZTEC to Fee Juice for an Alpha
Mainnet deployment: it would have been very easy to omit
--l1-private-key by mistake and have the command proceed anyway, silently
using the test mnemonic against --l1-chain-id 1.

Proposed Solution

When --l1-chain-id is a known real/live network (mainnet = 1, and
similarly any other non-local chain id) and neither --l1-private-key nor
an explicit --mnemonic was provided by the user, the CLI should refuse to
proceed by default, and require an explicit opt-in (e.g.
--i-know-this-uses-the-public-test-mnemonic) to continue anyway. At
minimum, print a loud, unmissable warning before signing/sending anything.

Known local/test chain ids (e.g. 31337 for Anvil/Hardhat, the default) can
keep today's silent behavior, since that's genuinely the intended use case
for this default.

Example Use Case

// Today: this silently derives the L1 signer from the public Hardhat/Anvil
// test mnemonic, even though --l1-chain-id 1 is Ethereum mainnet -- because
// --l1-private-key / --mnemonic was accidentally omitted.
// No warning, no error, no confirmation.

aztec-wallet bridge-fee-juice
30000000000000000000

--l1-rpc-urls "$L1_RPC_URL"
--l1-chain-id 1
--node-url https://aztec-mainnet.drpc.org
// (forgot --l1-private-key here)

// Desired: the command above should refuse to run and explain why, e.g.:
// Error: --l1-chain-id 1 looks like a real network, but no
// --l1-private-key or --mnemonic was provided -- refusing to sign with
// the public default test mnemonic. Pass --l1-private-key, your own
// --mnemonic, or --i-know-this-uses-the-public-test-mnemonic to proceed.

Alternative Solutions

Our own workaround is discipline-based: we always explicitly pass
--l1-private-key "$L1_PRIVATE_KEY" sourced from an environment variable,
never relying on the command's defaults. That works for us because we
already knew to look for this, but a new or less careful user gets zero
signal from the tool itself that the default is unsafe outside local test
networks.

Additional Context

Found in the same Alpha Mainnet deployment session as another issue we
filed about createSchnorrAccount silently deriving different addresses
across @aztec/wallets patch versions -- both surfaced while working through
a real mainnet deployment with real funds, where defaults that are fine for
local sandbox use turned out to have sharp edges once real money and a real
network were involved.