wallet subcommands are not network-aware (always operate on the default network's keystore)

[Reiers]

lantern wallet new|list|balance|export|import|default all use openWalletDefault() → build.DefaultNetwork — there is no --network flag. On a calibration or devnet node the wallet commands silently read/write the MAINNET keystore.

wallet send gained --network in PR #144; the rest should follow the same pattern (and walletBalance/walletList display should respect applyAddressNetwork, added in PR #145, so calibration addresses print t-prefixed).

Also worth doing while in there: wallet balance builds an offline ChainAPI against the mainnet gateway hardcoded (fetchTrustedHead(ctx, defaultGateway, build.Mainnet)) — should route through the running daemon like the new wallet send does.

[Reiers]

Correction after more digging: cmdWallet DOES resolve a wallet-level --network flag (resolveCLINetwork → cliWalletNetwork) and all wallet subcommands open the right keystore through openWalletDefault(). The real gaps are narrower:

1. wallet subcommands ignore network → only wallet send's own --network sub-flag defaulted to mainnet instead of the already-resolved cliWalletNetwork — fixed in c02be8e (live-verified on calibration: wallet send --network calibration pushed + landed, CID bafy2bzacearvlluvp3sxhcji7qoqy5mznieunvvmvul3wrt5yevgvo2djjysw, ExitCode 0 @ height 3916431).
2. Still open: wallet balance builds an offline ChainAPI against the hardcoded mainnet gateway + build.Mainnet trusted head — should route through the running daemon like the new wallet send.
3. Still open: CLI display prefix — wallet send echoed the recipient as f3... on calibration (parse-side is fine; the CLI process never calls applyAddressNetwork). One-liner per command entry point.

Scope reduced accordingly.