getdeploymentinfo keeps reporting threshold/possible while a deployment is LOCKED_IN

This description is AI generated, mistakes can be made.

Intent: Remove the deliberate suppression of threshold/possible once a deployment has locked in. rpc/blockchain.cpp only emits those two fields when threshold > 0 || possible, so zeroing them is how the RPC signals 'the threshold no longer applies'.

Behaviour change: While current_state == LOCKED_IN the original emits statistics with only period/elapsed/count; the mutant additionally emits "threshold": 108 and "possible": <whatever this period's signalling happens to give>, i.e. it tells the operator the fork can still fail to reach threshold when it is already irreversibly locked in.

Trigger: getdeploymentinfo on regtest at any height in [288, 431] (testdummy is LOCKED_IN there, with min_activation_height unreached only if configured; with default params it is LOCKED_IN for exactly one period): the bip9.statistics object gains threshold/possible, and possible reads false as soon as more than period-threshold blocks of the new period fail to signal.

Spec violation: Contradicts the RPC's own contract in rpc/blockchain.cpp (threshold/possible are only meaningful while signalling can still change the outcome) and BIP 9's LOCKED_IN semantics: once locked in, the transition to ACTIVE is unconditional.

Severity if undetected: low

Why tests miss it: rpc_blockchain.py:_test_getdeploymentinfo only samples heights 207 and 287, where current_state is 'started' and this branch is not taken on master either; grepped test/functional for 'locked_in' (one hit, that same status_next assertion) and src/test for VersionBitsCache::Info (no unit test exists); the fuzz target never calls Info

Plausibility: It reads like the removal of a redundant special case - the numbers it deletes are the same ones the statistics struct already carries - and the surrounding has_signal guard still mentions LOCKED_IN, so nothing looks obviously missing.

Equivalence risk: Nothing changes unless a caller inspects statistics while current_state is exactly LOCKED_IN, which is a one-period window per deployment.