BIP9 statistics are selected by the next block's state instead of the current one

This description is AI generated, mistakes can be made.

Intent: Swap the state that decides whether signalling information is applicable, so getdeploymentinfo reports (or hides) the statistics block for the wrong period at every state boundary.

Behaviour change: At the last block of a period where the state changes, the two disagree: with current_state == STARTED and next_state == FAILED or ACTIVE the mutant omits 'bit', 'statistics' and 'signalling' entirely from the RPC output for a period that did signal; with current_state == DEFINED and next_state == STARTED it emits them for a period in which signalling had no meaning yet.

Trigger: getdeploymentinfo at the last block of the period in which a deployment times out (STARTED -> FAILED) or activates (LOCKED_IN -> ACTIVE) - e.g. regtest testdummy at height 431 with default params: master reports the statistics/signalling of the just-finished period, the mutant reports none.

Spec violation: rpc/blockchain.cpp treats the statistics object as describing the period the queried block belongs to (its 'status', not its 'status_next'); BIP9Info documents stats as 'For states where signalling is applicable', i.e. the current state.

Severity if undetected: low

Why tests miss it: rpc_blockchain.py samples height 207 (started/started) and 287 (started/locked_in); has_signal is true under both readings at both heights, so the expected JSON is unchanged; no unit test or fuzz target calls VersionBitsCache::Info

Plausibility: current_state and next_state are computed two lines apart and used two lines later; picking the wrong one is a one-word slip, and the following line still reads if (LOCKED_IN == current_state) so the function looks internally consistent.

Equivalence risk: current_state and next_state are equal for all but the last block of a transitioning period, so the two versions agree on the overwhelming majority of queries.