Fix GRANDPA warp proofs for delayed changes

[prop-opentensor]

Summary

Warp sync currently breaks when a GRANDPA authority change is scheduled with a delay, because the proof format assumes the scheduling block and the justified handoff block are the same block.

On testnet, the change is scheduled on one block and only becomes effective on a later finalized descendant, so peers can serve warp proofs that clients cannot correctly decode or verify across that transition.

This PR fixes that by including the intermediate descendant headers in each warp proof fragment, so the verifier can connect the scheduling block to the justified target block and validate delayed authority handoffs correctly.

What this PR changes

• Extends WarpSyncFragment with descendant_headers, the contiguous header path from the block that scheduled the change to the later block justified by GRANDPA.
• Updates proof generation to walk back from each finalized authority-set boundary until it finds the scheduling digest, then encode that scheduling header plus the descendant path to the justified target.
• Updates verification to check that descendant chain, verify that the justification target matches its end, verify the justification against the pre-change authority set, and then apply the scheduled change from the original scheduling block.
• Adds regression coverage for delayed scheduled changes alongside the existing immediate-change case.

Why this is needed for testnet

Testnet has a historical delayed GRANDPA authority change at block 5534451. That transition exposes the assumption in the current warp proof format and is one of the reasons fresh nodes cannot warp sync from official peers today.

This SDK PR fixes the generic serving/verification bug. The chain-specific client-side companion change lives in the Subtensor PR: opentensor/subtensor#2551

Safety / scope

• no runtime logic changes
• no block import or finality rule changes
• immediate-change cases continue to work as before; they simply have an empty descendant_headers list
• affects only GRANDPA warp proof generation and verification
• does change the warp-proof wire encoding, so serving and consuming nodes need to run the same SDK revision during rollout

Test

• cargo test -p sc-consensus-grandpa warp_sync_proof_generate_verify --quiet