Add signet chain selector (selection::signet) to system settings

[dsbaars]

Summary

The chain::selection enum and the settings constructor do not include signet. Downstream consumers that need to recognize or configure the signet network cannot derive signet parameters (genesis block, ports, etc.) from system::settings and are forced to hardcode values. This issue requests a first-class signet selector.

Motivation

libbitcoin-server implements bitcoind-compatible RPC. Its getblockchaininfo reports a "chain" name, produced by a chain_name() helper that maps a network genesis hash to a name by comparing against system::settings{ selection::X }.genesis_block.hash() for mainnet, testnet, and regtest. Because there is no selection::signet, signet's genesis hash is currently hardcoded behind a TODO. This was introduced in libbitcoin-server PR #795.

Current state

• include/bitcoin/system/chain/enums/selection.hpp: the enum contains none, mainnet, testnet3, testnet4, regtest. There is no signet.
• src/settings.cpp: the switch over chain::selection has cases for mainnet, testnet3, testnet4, and regtest (near lines 79, 182, 276, and 367 on current master). There is no signet case.
• A grep for "signet" across include/ and src/ returns nothing.

Proposed change

1. Add signet to enum class selection in include/bitcoin/system/chain/enums/selection.hpp.
2. Add a case chain::selection::signet: block in src/settings.cpp alongside the existing cases, populating the network parameters: genesis_block, proof_of_work_limit, subsidy_interval_blocks, fork and BIP activation heights, checkpoints, default ports and seeds. settings::genesis_block (settings.hpp line 71) is the member that downstream consumers read.

Important complication (BIP 325)

Signet is not only a different genesis block. Under BIP 325, signet block validity depends on a signet challenge script that must be satisfied by a signature from the network operator, which replaces the standard proof-of-work difficulty check. system::settings has no field for a signet challenge today, and the chain-state and validation paths would need signet-aware rules. A correct signet selector is therefore a consensus level addition, not a configuration only toggle.

The default (global) signet uses a well-known challenge script and has a genesis block hash of:

00000008819873e925422c1ff0f99f7cc9bbb232af63a077a480a3633bee1ef6

Two possible scopes:

• Minimal: add the enum value and a settings case sufficient for network identification (genesis, ports, seeds), with an explicit note that full signet block validation is out of scope for this change.
• Full: add a signet challenge field plus signet-aware consensus and proof-of-work handling.

Downstream follow up (libbitcoin-server)

Once selection::signet exists, chain_name() in src/protocols/bitcoind/protocol_bitcoind_rpc_json.cpp can drop the hardcoded hash and use system::settings{ selection::signet }.genesis_block.hash(), matching the other networks. The server parser can then expose a signet network flag that resolves to selection::signet.

Acceptance criteria

• chain::selection::signet exists.
• system::settings{ chain::selection::signet } constructs with the correct signet genesis block and network parameters.
• A decision is recorded on whether signet block validation (the BIP 325 challenge) is in scope for this issue or tracked separately.

[thecodefactory]

IMO, if we're adding the signet enum, signet block validation should be included for usage outside of setting testing. The challenge field would of course be required in that case (in the settings).