Timewarp check gated with DeploymentActiveAt(*pindexPrev): not enforced on the first block of the activation period

This description is AI generated, mistakes can be made.

Intent: The timewarp rule only applies to blocks with N % 2016 == 0, which is exactly where activation happens. Checking the deployment state of the parent (the last LOCKED_IN block) skips the rule on the first active block.

Behaviour change: Original: the first block of the activation period is rejected with time-timewarp-attack if its timestamp is more than 7200s below its parent's. Mutant: that header is accepted, and the rule only starts one retarget period later.

Trigger: Activate consensuscleanup via signalling (as feature_bip54 does), then submit the header at activation height (N % 144 == 0 on regtest) with nTime = prev.nTime - 7201 (and above MTP).

Spec violation: BIP 54: 'if N % 2016 is equal to 0, the timestamp of the block must be set to a value higher than or equal to ... T_{N-1} - 7200' for all blocks after activation.

Severity if undetected: critical

Why tests miss it: bip54_tests.cpp bip54_timestamps (vectors run with consensuscleanup ALWAYS_ACTIVE, so At and After agree); feature_bip54.py timewarp_attack (run one full period after activation); mining_basic.py (bip94 path only)

Plausibility: DeploymentActiveAt(*pindexPrev) and DeploymentActiveAfter(pindexPrev) read almost the same. A contributor who reasons 'is the deployment active at the previous block?' writes the former, and at most heights it is equivalent.

Equivalence risk: Diverges only for the first block of the activation period. That block is precisely where a timewarp-restricted block can occur, so it is reachable, but only once per activation.