Mempool enforces the BIP54 sigops limit only when the deployment is active at the tip

This description is AI generated, mistakes can be made.

Intent: The PR moved the BIP54 sigops check out of the policy (ValidateInputsStandardness) and into CheckTxInputs, relying on the mempool always passing true. Gating it on deployment state means that while BIP54 is inactive (mainnet today), the mempool checks nothing at all.

Behaviour change: Original: on mainnet/testnet the mempool rejects a tx with >2500 legacy sigops (bad-txns-legacy-sigops), as the pre-PR policy did. Mutant: the tx is accepted and relayed. With -checkmempool, CTxMemPool::check (txmempool.cpp:534, enforce_bip54=true) then asserts. At activation, such txs left in the mempool make CreateNewBlock produce BIP54-invalid templates.

Trigger: Mainnet (or regtest with -vbparams=consensuscleanup:0:0) node: sendrawtransaction of mempool_sigoplimit.py's 2505-legacy-sigop P2SH spend. The mutant accepts it into the mempool.

Spec violation: Documented intent of the PR ('the BIP 54 sigops check can't be bypassed anymore in the mempool'); the removed pre-PR standardness rule (bad-txns-nonstandard-inputs, non-witness sigops exceed bip54 limit) is no longer enforced anywhere.

Severity if undetected: high

Why tests miss it: mempool_sigoplimit.py, feature_bip54.py (pre-activation section only submits blocks), transaction_tests.cpp (calls CheckTxInputs directly with true), grep -vbparams=consensuscleanup in test/functional

Plausibility: Gating a soft-fork rule on deployment state using the tip is a standard pattern, and the comment just above ('The mempool holds txs for the next block') invites it. A reviewer could easily see it as more correct than an unconditional true.

Equivalence risk: On regtest, where the deployment is always active, nothing changes. The difference shows only on networks where BIP54 is inactive, which today is every public network.