IsOutboundOrBlockRelayConn returns false for reconciliation connections

This description is AI generated, mistakes can be made.

Intent: Exempt recon peers from the outbound chain-sync eviction logic (ConsiderEviction) and from the insufficient-work headers disconnect. Arguably high, since recon slots are the anti-eclipse fallback and a lagging/stale peer could hold them indefinitely, but the 8 full-relay peers keep their eviction, so labelled medium.

Behaviour change: Original: a recon peer whose best known header lacks our tip's work gets a chain-sync timeout and is disconnected, and one sending a headers chain below minimum chain work is disconnected. Mutant: neither happens; the peer keeps its slot.

Trigger: Node with -txreconciliation opens an OUTBOUND_FULL_RECONCILIATION peer that negotiates SENDTXRCNCL but never announces headers reaching our tip; after CHAIN_SYNC_TIMEOUT+HEADERS_RESPONSE_TIME, ConsiderEviction skips it. Or the peer sends a headers chain ending below nMinimumChainWork on mainnet.

Spec violation: Commit 'Count reconciliation connections as full outbound connections': 'chain sync: they can be protected from the bad/lagging chain logic, which they are already subject to via IsOutboundOrBlockRelayConn.'

Severity if undetected: medium

Why tests miss it: rg IsOutboundOrBlockRelayConn src/test test/functional; pr-tests.diff (denialofservice tests only use eviction of extras, not stale-tip eviction for recon); p2p_txrecon_* use clean regtest chains

Plausibility: Moving a case between the true/false groups of a switch is a one-line diff; a reader might reason recon conns are 'not block-relay' and belong with the false set.

Equivalence risk: Only matters for recon peers with lagging/insufficient chains; such a peer is reachable in practice, so behaviour differs.