No advance warning while an unknown softfork is merely LOCKED_IN

This description is AI generated, mistakes can be made.

Intent: Drop the half of this function's documented contract that reports deployments which are locked in but not yet active, removing the one retarget period (~2 weeks on mainnet) of advance notice an operator gets before unknown rules start being enforced.

Behaviour change: Original returns (bit, false) while the unknown deployment is LOCKED_IN, and validation.cpp logs 'Unknown new rules activated (versionbit N)' with each new tip as a pre-activation warning; the mutant returns nothing until the deployment is already ACTIVE, at which point the operator is told only after the fact.

Trigger: Any chain where an unknown bit passes the signalling threshold: during the following retarget period master emits the warning in the UpdateTip log line, the mutant emits nothing.

Spec violation: versionbits.h: 'Returns a vector containing the bit number used for signalling and a bool indicating the deployment is likely to be ACTIVE, rather than merely LOCKED_IN' - the bool exists precisely because LOCKED_IN is reported too.

Severity if undetected: low

Why tests miss it: feature_versionbits_warning.py only asserts the persistent warning (kernel::Warning::UNKNOWN_NEW_RULES_ACTIVATED, i.e. the ACTIVE branch) via getmininginfo/getnetworkinfo and the alertnotify file; the LOCKED_IN branch only reaches warning_messages -> UpdateTipLog, and no test greps debug.log for it; no unit test calls CheckUnknownActivations

Plausibility: The leftover state == ACTIVE argument in the emplace_back looks like a tidy-up artifact rather than a symptom, and 'only warn about what actually activated' is an argument a reviewer might accept on its face.

Equivalence risk: The ACTIVE warning still fires one period later, so on any chain observed over time the operator eventually sees the same message - only the early notice is lost.