Reconciliation peers occupy full-relay slots in ThreadOpenConnections

This description is AI generated, mistakes can be made.

Intent: Fold recon peers into nOutboundFullRelay. When a full-relay peer drops, the node does not replace it while 8 or more full-relay plus recon peers remain. Over time it ends up with only 4 recon peers and no fanout full-relay peers. Tx propagation degrades to reconciliation only, and the anti-eclipse design (8 normal full-relay plus recon fallback) falls apart. Rated medium, not high, because no attacker action is needed and the chain stays intact.

Behaviour change: Original: 7 full-relay plus 4 recon peers gives nOutboundFullRelay = 7, so a full-relay peer is opened. Mutant: nOutboundFullRelay = 11, so no full-relay peer is opened, and the recon branch is also skipped. The node stays below its full-relay target until restart.

Trigger: A node with -txreconciliation at 8 full-relay and 4 recon peers. One full-relay peer disconnects (normal churn or stale-tip eviction) and is never replaced. Repeated drops reduce full-relay to 4 or fewer, and the node keeps going with only 4 recon peers.

Spec violation: Code comment (removed by the mutant): 'Count the slots per connection type, so IsFullOutboundConn() ... is not what we want here.'

Severity if undetected: medium

Why tests miss it: rg ThreadOpenConnections / nOutboundFullRelay in src/test and test/functional; functional tests use -connect=0 and addconnection; fuzz/connman does not run the thread

Plausibility: This is exactly the pre-PR line. A rebase conflict resolution or a 'simplification' back to the helper whose docs say both types are 'full outbound' would produce it.

Equivalence risk: With no recon peers (txreconciliation off, the default) it is identical. It diverges only when recon peers exist, which is the feature's purpose.