[chainstate] The Stacks canonical tip rule must first rank by tenure ID consensus hash

[jcnelson]

Suppose that the signer set's signing keys from a prior reward cycle, as well as a miner's signing key, got leaked. Then, someone could create a valid-looking Stacks fork, complete with up-to-date burn view consensus hashes, which would be longer than the canonical fork.

Right now, such a malicious fork would be treated as the canonical fork, because the rules for updating the canonical Stacks tip do not consider the Bitcoin height of the block's tenure. If we first ordered Stacks forks by their tenure's Bitcoin height, then this attack would not work -- Stacks forks created with tenures in subsequent reward cycles would be ranked higher, and the attacker (who does not have a later reward cycle's signing keys) would be unable to produce a malicious canonical fork.

The fix would be to only allow the memoized canonical Stacks tip to advance if the tip has the same or later tenure ID consensus hash within its Bitcoin fork.

[Rapha-btc]

Since a single tenure can contain many Stacks blocks, an attacker with leaked signer + miner keys from a past cycle could produce far more blocks in that tenure than the real chain has — making their fork longer. Longest fork wins, so it takes over.