Two-stage chain detection: resolve testnet/signet/regtest ambiguity via API

[8144225309]

Context

PR #22 adds client-side chain detection that scans decoded TX output addresses and shows a dynamic banner identifying the target network. This works instantly but has inherent ambiguity — some address prefixes map to multiple chains.

Address Prefix Ambiguity Matrix

Prefix	Could be
bc1...	Mainnet only
bcrt1...	Regtest only
tb1...	Testnet OR Signet
1.../3...	Mainnet only
m.../n.../2...	Testnet OR Signet OR Regtest

Proposed Two-Stage Detection

Stage 1: Instant (client-side, implemented in PR #22)

Detect address prefix → show banner with best guess. For tb1... it says "TESTNET" but could be signet. For m/n/2 it says "TESTNET" but could be regtest. Fast, no network round-trip.

Stage 2: Resolved (future, API call)

Query an endpoint like /api/check-address?addr=tb1q... that hits the server's configured RPC node. The server asks its Bitcoin node "do you know this address?" — if the node is signet and recognizes it, the banner updates to "SIGNET (confirmed)". This resolves the ambiguity. Single API call, definitive answer.

Edge Cases

• Same UTXO on both testnet and regtest: Rare but possible. Resolution: whichever node the server is connected to will answer. If the server runs both, it could check both and show "Found on TESTNET and REGTEST."
• Ambiguous banner text: During stage 1, for tb1... addresses the banner could say "TESTNET / SIGNET" with a note that resolution requires an API call.
• Mixed outputs: A TX with outputs on different detected chains would show a warning about mixed network addresses.

Related

• PR Fix visual parity across all vanilla HTML pages #22 implements stage 1
• network.c already has detect_address_network() with full prefix matching (currently UNHOOKED)
• network_check_address() handles the ambiguity logic server-side (also UNHOOKED)