BIP94 retarget base taken from the last block of the previous period instead of the first block of the current one

This description is AI generated, mistakes can be made.

Intent: Brings back the testnet block-storm bug BIP94 fixed: the retarget base can be a 20-minute-exception block at difficulty 1. At the first retarget (nHeight 2015), nHeightFirst is -1, GetAncestor returns nullptr, and the next line dereferences it, so testnet4 IBD crashes. Rated medium because this breaks testnet4 consensus/availability only. On mainnet it would be critical, but mainnet does not enforce BIP94.

Behaviour change: Original: bnNew starts from the nBits of the block at height (N-2015), the first block of the closing period. Mutant: it starts from height (N-2016), the previous period's last block, whose nBits may be 0x1d00ffff. The next target is computed differently, so valid testnet4 retarget blocks are rejected with bad-diffbits. At height 2015 the node null-derefs.

Trigger: Syncing testnet4 from genesis: validating block 2016 calls GetNextWorkRequired -> CalculateNextWorkRequired with pindexLast at height 2015, so GetAncestor(-1) returns nullptr and pindexFirst->nBits crashes. On a later retarget where block N-2016 used the 20-minute exception, the target differs.

Spec violation: BIP94: 'For difficulty adjustment calculations between periods: The base difficulty value MUST be taken from the first block of the previous difficulty period'.

Severity if undetected: medium

Why tests miss it: grep -rn 'enforce_BIP94|BIP94|TESTNET4|testnet4' src/test test/functional: only argsman tests and ChainParams_TESTNET4_sanity (no retarget). pow_tests and fuzz pow use MAIN params (enforce_BIP94=false)

Plausibility: 'Go back one interval' without the -1 is the natural first draft, and a reviewer comparing it with GetNextWorkRequired may not notice the missing -1.

Equivalence risk: None on testnet4. It is unreachable on mainnet/signet/regtest/testnet3, where enforce_BIP94 is false.