CheckUnknownActivations never scans the top BIP 323 signalling bit

This description is AI generated, mistakes can be made.

Intent: Shorten the warning scan to bits 0..3, leaving bit 4 - a perfectly valid BIP 323 signalling bit - completely unmonitored.

Behaviour change: An unknown softfork deployed on bit 4 locks in and activates without the node ever emitting 'Unknown new rules activated (versionbit 4)', so the operator gets no indication that the network may be enforcing rules this node does not know. Bits 0..3 behave as before.

Trigger: A mainnet (or regtest) chain in which >=90% (75% on test chains) of a retarget period sets bit 4 and no known deployment uses it: master warns and fires -alertnotify, the mutant is silent forever.

Spec violation: BIP 323: bits 5..28 'are reserved for nonce use and removed from BIP8 and BIP9 specifications ... bits 5-28 inclusive will be ignored for soft-fork signalling and unknown soft-fork warnings' - i.e. bits 0..4 inclusive must still be watched, which is exactly what VERSIONBITS_NUM_BITS == 5 encodes.

Severity if undetected: medium

Why tests miss it: feature_versionbits_warning.py is the only test of this function and uses VB_UNKNOWN_BIT = 3 (its VB_IGNORED_BIT = 5 is already outside the loop on master); grepped src/test for CheckUnknownActivations and m_warning_caches - no unit test or fuzz target covers them

Plausibility: 'NUM_BITS - 1' reads like an author who thinks of the constant as the highest usable bit index, and the loop still visibly covers 'the versionbits range', so a reviewer scanning for the usual <= mistake sees nothing alarming.

Equivalence risk: No difference at all unless something actually signals on bit 4; every other bit is still scanned, so the warning system looks fully functional in testing.