Reconciliation peers are excluded from netgroup and privacy-network diversity accounting

This description is AI generated, mistakes can be made.

Intent: Recon peers' netgroups never enter outbound_ipv46_peer_netgroups. Several recon peers, or a recon peer and a full-relay peer, can then sit in the same /16. An attacker who controls one netgroup can take all of the reconciliation slots, which exist as the anti-eclipse fallback.

Behaviour change: Original: an addrman candidate in the same netgroup as an existing recon peer is skipped. Mutant: it is accepted. outbound_privacy_network_peers also leaves out Tor/I2P/CJDNS recon peers.

Trigger: A node with -txreconciliation and addrman flooded with addresses from one /16 (for example via ADDR messages from an attacker). As recon slots open, ThreadOpenConnections can fill all 4 with peers from that /16 and can then open full-relay peers into the same group.

Spec violation: Code comment: 'Make sure our persistent outbound slots to ipv4/ipv6 peers belong to different netgroups.' Recon slots are persistent outbound slots.

Severity if undetected: high

Why tests miss it: rg outbound_ipv46_peer_netgroups / netgroup across src/test and test/functional; functional recon tests use addconnection on 127.0.0.1, and nothing drives ThreadOpenConnections

Plausibility: Reconciliation peers look like 'extra' connections, much like feelers. Putting the new enum value next to the short-lived types is an easy grouping mistake, and the switch still covers every case, so -Wswitch stays quiet.

Equivalence risk: It matters only when an addrman candidate shares a netgroup with a recon peer. On a real network that is rare without an attacker, but an attacker can make it happen.