ConnectBlock gates BIP54 sigops with DeploymentActiveAfter(pindex) instead of DeploymentActiveAt(*pindex), enforcing one block early

This description is AI generated, mistakes can be made.

Intent: Off-by-one on activation height: the 2500-sigop rule is applied to the block whose child is the first active block, i.e. the last block of the LOCKED_IN period.

Behaviour change: Original: the last LOCKED_IN block is connected without the BIP54 sigops check. Mutant: that block is rejected with bad-txns-legacy-sigops if it contains a tx with more than 2500 legacy sigops.

Trigger: On a chain where consensuscleanup goes LOCKED_IN -> ACTIVE, mine a block at height (activation_height - 1) that contains a transaction spending inputs worth 2501 legacy sigops (e.g. feature_bip54's create_txs_many_sigops). Unmutated nodes accept it; the mutant rejects it in ConnectBlock.

Spec violation: BIP 54: 'For all blocks after activation the following new rules apply.' A pre-activation block must not be subject to the sigops limit.

Severity if undetected: critical

Why tests miss it: feature_bip54.py run_test (sigops submitted only well before or after activation), bip54_tests.cpp (sigops tested via CheckSigopsBIP54/CheckTxInputs directly), transaction_tests.cpp, grep consensuscleanup in test/functional

Plausibility: Every other BIP54 gate the PR adds is DeploymentActiveAfter(pindexPrev, ...), so writing DeploymentActiveAfter(pindex, ...) here looks consistent at a glance. The At/After-on-current-vs-prev distinction is easy to miss in review.

Equivalence risk: Differs only on the single block before activation, and only if it has a >2500-sigop tx. A soft-fork activation is a one-time event, but a miner can deliberately include such a tx and split mutant nodes off.