fix(drive-abci): local ChainLock verification rejects a valid ChainLock signed by a quorum mined mid-window #5438

In a local network upgrade rehearsal (7 evonodes, llmq_test), the block right after protocol version 14 activated took 4 rounds. Besides a stopped node, Drive logged InvalidChainLock 'invalid based on platform state' from verify_chain_lock_locally for a ChainLock that Core had accepted. The ChainLock appears to have been signed by a quorum that was mined mid-window, which Platform's stored quorum state did not account for.

This looks pre-existing (not introduced by 5.0) and costs liveness, not safety, as far as observed. To do: find exactly which valid ChainLocks local verification rejects and why, reproduce it in a test, and fix it (versioned if it changes which blocks are accepted).