IsFullOutboundConn no longer counts reconciliation connections

This description is AI generated, mistakes can be made.

Intent: Recon peers stop counting towards GetFullOutboundConnCount (seednode/DNS-seed threshold) and are never granted the bad/lagging-chain protection from their own budget in ProcessHeadersMessage.

Behaviour change: Original: a recon peer that sends headers matching our tip work gets m_chain_sync.m_protect (up to MAX_RECONCILIATION_PEERS_TO_PROTECT_FROM_DISCONNECT=2) and counts toward SEED_OUTBOUND_CONNECTION_THRESHOLD. Mutant: no recon peer is ever protected (so all recon peers stay eviction candidates on stale tip), and m_recon_peers_with_protect_from_disconnect stays 0; seed queries continue with recon peers present.

Trigger: Node with -txreconciliation connected to recon peers that send headers at our tip work: ProcessHeadersMessage skips the protection block at net_processing.cpp:3270.

Spec violation: Doc comment: 'Check is this a full outbound connection. Both fanout and reconciliation count'; commit message 'Reconciliation peers get their own, smaller protection budget'.

Severity if undetected: medium

Why tests miss it: src/test/net_tests.cpp (checks only FULL_RELAY/BLOCK_RELAY/INBOUND/etc nodes), fuzz/connman.cpp (void casts), rg MAX_RECONCILIATION_PEERS_TO_PROTECT in src/test (no hits), pr-tests.diff

Plausibility: This is exactly the base-commit body; a rebase or a split of the PR could easily drop the second clause, and IsOutboundReconciliationConn exists alongside so it looks redundant.

Equivalence risk: In unit eviction tests no peer is protected anyway, so they cannot tell; behaviour differs once real headers arrive from recon peers.