fix(electrum): serve server.features independently of peer discovery

[HusseinAdeiza]

Closes #229

server.features was tied to peer discovery two ways: the dispatch arm is #[cfg(feature = "electrum-discovery")], and even inside gated builds the handler unwrapped the discovery manager and errored ("discovery is disabled", -32603) whenever the server was started without --electrum-public-hosts. Electrum >= 4.7.0 calls server.features on connect, so a default-feature electrs build with no public hosts is simply unreachable from the wallet (spesmilo/electrum#10281, reported in the issue).

ServerFeatures itself never needed discovery: the struct is already ungated, and all the data (hosts, version, genesis, protocol range) comes from the config. This builds the features once in RPC::start, hands every connection an Arc<ServerFeatures>, and registers the method in every build. Discovery stays opt-in, exactly as before: it is still only started when public hosts are set, and the manager gets the same features value. The electrum_public_hosts config field loses its cfg gate so non-discovery builds can still report real hosts (parsed as None there, since the CLI flag lives in the gated block).

This mirrors the fix mempool/electrs carries in PR 150 (merged upstream there on 2026-06-03).

Tests: new test_electrum_server_features_without_public_hosts in tests/electrum.rs runs a raw TCP server.features against the default harness config (hosts = None), same pattern as test_electrum_raw. On current master that request fails, -32603 inside gated builds or unknown-method with --no-default-features; with the patch it returns the features object.

cargo check --all-targets passes with default features and with --no-default-features. The new integration test needs the electrsd harness to fetch bitcoind, which is heavy to provision locally; it will run in CI here, and I have the same command green locally if it finishes before review.

[EddieHouston]

Thanks for opening this PR. This looks like a faithful port of mempool/electrs#150.

One edge case shared with that implementation: genesis_hash(config.network_type) returns an all-zero placeholder for Liquid testnet and regtest. The helper’s comment assumes it is only used for discovery, but this change exposes it through server.features in every build.

Could we use the indexed block hash at height 0 instead? That would also handle configurable Elements regtest genesis blocks. A test asserting the actual genesis hash would catch this; the new test currently only checks that it’s a string and is disabled for Liquid.

[HusseinAdeiza]

Good catch — switched to the indexed height-0 hash, so it's correct for Liquid testnet/regtest and configurable Elements regtest genesis. RPC::start runs after the initial sync, so height 0 is already indexed; I kept a genesis_hash() fallback just in case.

Also strengthened the test to assert the returned hash equals the daemon's height-0 block hash instead of just checking it's a string.