feat(spamoor): support auto-starting built-in default spammers

[pk910]

spamoor: support auto-starting built-in default spammers

Summary

Spamoor is getting a reworked default-spammer system (ethpandaops/spamoor#254): built-in defaults are inserted on first launch and can be auto-started by a stable technical key via the new --startup-defaults flag. This PR exposes that feature through spamoor_params, so a devnet can start the built-in "Regular Chain Load" and "Fuzzing" groups (or any other default) without defining its own startup spammers.

Changes

New spamoor_params options (all default to off/empty, so existing configs are unaffected):

spamoor_params:
  # Start spamoor's built-in "Regular Chain Load" default group on first launch
  # (a balanced mix of everyday transaction types sharing a global throughput budget)
  start_chainload: false
  # Start spamoor's built-in "Fuzzing" default group on first launch
  # (EVM execution and transaction-layer fuzzing under a shared throughput budget)
  start_fuzzing: false
  # A list of additional built-in spamoor defaults (by technical key) to start on first launch
  defaults: []

• start_chainload / start_fuzzing map to the built-in default group keys regular-chain-load / fuzzing.
• defaults accepts any built-in default key (e.g. eoatx-heavy, blob-average, gas-burner); entries are deduplicated against start_chainload / start_fuzzing, so overlapping values don't conflict.
• If any keys are collected, the spamoor-daemon launch command gets --startup-defaults=key1,key2,... appended.
• The new sub-params are registered in the sanity check and documented in README.md / network_params.yaml.

Dependency

⚠️ Depends on ethpandaops/spamoor#254 — the --startup-defaults flag does not exist in current spamoor releases (latest: v1.2.2). This PR must wait for the next spamoor release containing that change; until then the flag would make spamoor:latest fail to start when any of the new options are enabled (defaults-off configs are unaffected).

Testing

• kurtosis lint passes.
• Flag plumbing follows the existing spamoor_params field patterns (input parser defaults → struct → sanity check → service cmd).

[barnabasbusa]

I'd argue to enable this by default.

If you assume someone to add spamoor in their list, I'd expect spamming to happen.