mempool: guard removeProTxKeyChangedConflicts against already-removed entries

The eviction loop dereferenced mapTx.find(txHash) without checking for end().
If two stale provider updates for one masternode form a parent/child chain,
removeRecursive() on the parent also evicts the child, so the child's saved
hash then resolves to mapTx.end() and dereferencing it can crash the node.
This is a pre-existing hazard in the conflict-eviction path (surfaced while
reviewing the shared-masternode changes to this function); guard the lookup and
skip entries already gone.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Author: PastaPastaPasta

src/txmempool.cpp

@@ -1065,8 +1065,14 @@ void CTxMemPool::removeProTxKeyChangedConflicts(const CTransaction &tx, const ui
         }
     }
     for (const auto& txHash : conflictingTxs) {
-        auto& tx = mapTx.find(txHash)->GetTx();
-        removeRecursive(tx, MemPoolRemovalReason::CONFLICT);
+        // An earlier removeRecursive() may have already evicted this entry as a descendant of a
+        // previously-processed conflict, so it can be absent here; dereferencing mapTx.end() would
+        // crash. (Pre-existing hazard; guarded here to be safe.)
+        auto it = mapTx.find(txHash);
+        if (it == mapTx.end()) {
+            continue;
+        }
+        removeRecursive(it->GetTx(), MemPoolRemovalReason::CONFLICT);
     }
 }