fix(mempool): conflict ProRegTx collateral reuse with in-mempool masternode updates

[PastaPastaPasta]

Issue being fixed or feature implemented

A ProRegTx that reuses an external collateral replaces the masternode that collateral
currently backs — the old masternode ceases to exist and its proTxHash becomes unknown.

The mempool does not model that. It tracks collateral spends
(removeProTxSpentCollateralConflicts), but reuse is not a spend, so:

• A replacement ProRegTx and an update (ProUpServTx / ProUpRegTx / ProUpRevTx) targeting the
  masternode being replaced can sit in the mempool at the same time.
• If both are selected into one block, BuildNewListFromBlock() deletes the masternode when
  it applies the ProRegTx, then fails bad-protx-hash on the update.
• That aborts block assembly in the miner.

The same hazard exists when the replacement ProRegTx arrives in a block rather than through
the mempool: the stale update is left behind and can never be mined.

What was done?

Three commits.

1. Mempool admission (existsProviderTxConflict) — the two directions are now
symmetric:

• A ProRegTx reusing an external collateral conflicts if any mempool transaction still
  references the incumbent masternode's proTxHash.
• A ProUpServTx / ProUpRegTx / ProUpRevTx conflicts if a pending ProRegTx already claims its
  masternode's collateral outpoint.

This is first-in-wins with no RBF-style tiebreak. That is a deliberate policy choice: both
transactions are individually valid, and the only requirement is that they not coexist.
Preferring the incumbent would mean evicting an already-accepted transaction on arrival of a
new one, which is a bigger policy change than this problem warrants.

2. Eviction on block connect (removeProTxConflicts) — when a collateral-reusing
ProRegTx is mined, any mempool transaction still targeting the replaced masternode is
removed. This covers the case where the ProRegTx never passed through this node's mempool,
so the admission check above never ran.

3. Refactor — the removal loop inside removeProTxSpentCollateralConflicts is extracted
as CTxMemPool::removeProTxReferences() and reused by both call sites. No behaviour change;
it just avoids a second copy of the iterator-invalidation-safe loop.

One thing reviewers should look at

The eviction in (2) calls dmnman->GetListAtChainTip() and needs it to resolve to the list
at the previous tip, so GetMNByCollateral() returns the masternode being replaced rather
than its replacement. That holds because CDeterministicMNManager::tipIndex is assigned in
UpdatedBlockTip(), which fires from ActivateBestChain() (validation.cpp:3339-3340) —
after ConnectTip() calls removeForBlock() (validation.cpp:3025).

removeProTxSpentCollateralConflicts() already depends on this ordering, so the new code is
consistent with the file. The difference is that there it is an optimisation, whereas here it
is load-bearing: if the ordering changed, GetMNByCollateral() would return the replacement
masternode and the eviction would silently become a no-op. I have noted the dependency in a
comment, but flagging it explicitly since it is the least obvious part of the change.

How Has This Been Tested?

test_mempool_proreg_replacement_update_conflict in
src/test/evo_deterministicmns_tests.cpp, added in the commit preceding the fix. It
covers both paths:

• admission, via existsProviderTxConflict() in both directions;
• eviction, via removeForBlock() with a block containing the replacement ProRegTx.

Without the fix the admission assertions fail (2 failures) — the conflicting pair is
accepted. With the fix, evo_dip3_activation_tests passes (19 cases).

Built and run on macOS/arm64 against current develop.

Breaking Changes

Mempool policy only; no consensus rules change. Some transaction pairs that were previously
accepted together are now mutually exclusive in the mempool. Neither could have been mined
together, so nothing that was previously minable is rejected.

Known follow-up

Coverage is C++ unit level only. A functional test exercising the miner path end to end
would strengthen this; happy to add one in this PR if reviewers would prefer it before merge.

Checklist:

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated relevant unit/integration/functional/e2e tests
• I have made corresponding changes to the documentation
• I have assigned this pull request to a milestone