anvil v1.7.1 CLI binary auto-mines per eth_sendTransaction by default; diverges from NodeConfig::default() and breaks batch-sim contracts

## Summary In v1.7.1, the CLI binary and the library-embeddable `NodeConfig::default()` diverged on the auto-mining default: - **CLI binary** (`anvil` invoked from the shell): auto-mines a fresh block for every `eth_sendTransaction` by default. To get batch-style behavior (one block per batch), the caller must pass `--no-mining` AND explicitly fire `evm_mine` after the batch. - **In-process embedding via `NodeConfig::default()` + `anvil::spawn()`**: batches RPC-batched txs into one block correctly without any extra config. This divergence is undocumented and breaks downstream wrappers expecting library-style behavior from the CLI binary. At [Hypernative](https://hypernative.io) we wrap the CLI binary in a Go service that depends on "batch-sim contract: all batch txs share one block." With v1.7.1's CLI default, the contract silently breaks (tx 0 lands in block N, tx 1 in block N+1, etc.). ## Reproduce ```bash anvil --port 8545 & # Send two txs in a JSON-RPC batch: curl -sS http://localhost:8545 -H 'Content-Type: application/json' \ -d '[{"jsonrpc":"2.0","id":1,"method":"eth_sendTransaction","params":[{"from":"...","to":"...","value":"0x1"}]}, {"jsonrpc":"2.0","id":2,"method":"eth_sendTransaction","params":[{"from":"...","to":"...","value":"0x1"}]}]' # Tx 0 lands in block N, tx 1 lands in block N+1 — each in its own block. ``` vs. the equivalent via embedding (`NodeConfig::default().spawn()` and the same RPC batch) where both end up in block N. ## Asks - **(Preferred.)** Align the CLI default with `NodeConfig::default()` — no auto-mining unless explicitly requested via `--block-time` or similar. - **(Fallback.)** Document the divergence prominently in the v1.7.1+ release notes and in `anvil --help` so callers know to pass `--no-mining` for batch use cases. ## Current downstream workaround Pass `--no-mining` when spawning the CLI binary, then issue an explicit `evm_mine` RPC after each batch's `SendRawTransactionBatch` / `SendTransactionBatch`.