signalling_blocks is filled newest-first, reversing the getdeploymentinfo signalling string

This description is AI generated, mistakes can be made.

Intent: Break the chronological ordering of the per-block signalling vector that rpc/blockchain.cpp renders as the 'signalling' string of '#' and '-' characters; the walk is backwards, so indexing by elapsed instead of by the remaining-block counter reverses it.

Behaviour change: For a period whose blocks signalled in the pattern '##--#' the original returns '##--#' and the mutant returns '#--##'. Identical whenever all (or no) blocks in the period signal. Vector bounds are unaffected (elapsed-1 runs 0..size-1), so there is no exception, just wrong data.

Trigger: getdeploymentinfo on a chain where signalling is mixed within the current period - e.g. regtest testdummy after mining 3 signalling blocks and then 2 blocks with -blockversion set to a non-signalling value: the 'signalling' field reads '--###' instead of '###--'.

Spec violation: rpc/blockchain.cpp documents the field as the per-block signalling record of the period in block order ('identifies blocks that signalled with # and blocks that did not with -'), which consumers index by position within the period.

Severity if undetected: low

Why tests miss it: grepped 'signalling' in test/functional (only rpc_blockchain.py, whose period is 100% signalling so the string is all '#' either way) and in src/test (only the fuzz target)

Plausibility: elapsed - 1 looks like the obvious index of 'the block we just examined', and the alternative (blocks_in_period after its decrement) is genuinely obscure; a reviewer has to notice that the loop walks backwards to see the difference.

Equivalence risk: Invisible unless the period contains both signalling and non-signalling blocks, and invisible to any consumer that only counts '#' characters.