Off-by-one: ThreadOpenConnections opens one reconciliation peer beyond the budget

This description is AI generated, mistakes can be made.

Intent: The node opens 5 recon connections where the budget is 4. The 5th one takes the feeler semaphore slot, and the eviction logic then removes a recon peer again, so the node churns forever.

Behaviour change: Original: no recon connection is opened once 4 exist. Mutant: a 5th is opened. When it finishes the handshake, extra.reconciliation == 1 and the youngest recon peer is evicted after 30s, then reopened, and so on. While the 5th recon peer holds an outbound semaphore slot, feelers and extra block-relay or stale-tip peers are blocked.

Trigger: A node with -txreconciliation that already has 8 full-relay, 2 block-relay and 4 recon peers. The next ThreadOpenConnections iteration picks OUTBOUND_FULL_RECONCILIATION instead of a feeler or extra peer.

Spec violation: PR description: 'we are adding 4 additional reconciliation-only connections'. MAX_OUTBOUND_FULL_RECON_CONNECTIONS is the budget.

Severity if undetected: medium

Why tests miss it: rg ThreadOpenConnections and m_max_outbound_full_recon in src/test and test/functional; reconciliation_peer_eviction adds nodes by hand ('mocks logic in ThreadOpenConnections') and never runs it

Plausibility: A one-character boundary slip in a chain of '<' comparisons. A reviewer scanning the else-if ladder easily misses it.

Equivalence risk: The semaphore caps total automatic outbound at full+recon+block+feeler. The 5th recon peer still fits in the feeler slot, so the overshoot happens.