Coinbase nLockTime/nSequence rule gated with DeploymentActiveAt(*pindexPrev): skipped on the first active block

This description is AI generated, mistakes can be made.

Intent: Off-by-one on activation: the coinbase-locktime rule takes the parent's deployment state, so the first block of the activation period can carry a non-timelocked coinbase.

Behaviour change: Original: the block at activation height whose coinbase has nLockTime != height-1, or nSequence == 0xffffffff, is rejected (bad-cb-locktime / bad-cb-sequence). Mutant: it is accepted.

Trigger: On activation of consensuscleanup, submit the first block of the active period with a coinbase nLockTime of 0 (or a final nSequence), as feature_bip54's submit_nontimelocked_cb does but at the activation height.

Spec violation: BIP 54: 'The coinbase transaction's nLockTime field must be set to the height of the block minus 1 and its nSequence field must not be equal to 0xffffffff.' This applies to all blocks after activation.

Severity if undetected: critical

Why tests miss it: bip54_tests.cpp bip54_coinbase (consensuscleanup:-1:-1 ALWAYS_ACTIVE), feature_bip54.py submit_nontimelocked_cb (post-activation call happens many blocks after the boundary)

Plausibility: Same At-vs-After confusion as above. The nHeight > 0 guard makes dereferencing pindexPrev look deliberately safe.

Equivalence risk: Only one block per activation (the first active one) diverges. A miner who wants to split upgraded nodes from mutant nodes can use it deliberately.