Caplin custom devnets should support explicit CL bootnodes without inheriting mainnet defaults

## Problem

Caplin bootnodes for a custom devnet are configured through `--sentinel.bootnodes`, but that relationship is not obvious from the available Caplin flags:

- `--bootnodes` configures EL discovery.
- `--caplin.custom-config` accepts a config file, not a network config directory.
- There is no `--caplin.bootnodes` flag.
- `--sentinel.bootnodes` is copied into `CaplinConfig.BootstrapNodes` and then overrides `NetworkConfig.BootNodes`.

The custom consensus config cannot provide bootnodes either, because `NetworkConfig.BootNodes` has `yaml:"-"`.

There is also a surprising default: `CustomConfig` starts from the mainnet network config. Since bootnodes are excluded from YAML decoding, a custom devnet without `--sentinel.bootnodes` retains the mainnet Caplin bootnode list.

Relevant code:

- `cmd/utils/flags.go`: maps `--sentinel.bootnodes` to `CaplinConfig.BootstrapNodes`
- `cmd/caplin/caplin1/run.go`: overrides `networkConfig.BootNodes` only when the CLI list is non-empty
- `cl/clparams/config.go`: excludes `BootNodes` from YAML and initializes custom configs from mainnet defaults

## Expected behavior

Custom Caplin devnets should have an explicit, discoverable way to configure CL bootnodes and should not silently inherit mainnet bootnodes.

Possible directions:

1. Add a clearly named Caplin flag such as `--caplin.bootnodes`, keeping `--sentinel.bootnodes` as a compatibility alias.
2. Support loading CL bootnodes from the devnet network/config directory.
3. At minimum, initialize custom devnets with an empty bootnode list and document `--sentinel.bootnodes`.

The chosen behavior should keep built-in network bootnode defaults unchanged.