fix: bind checkpoint transition queues to the verified terminal header

[matthias-wright]

Builds on #422 (which builds on #402)

Addresses #216.

Changes:

• types/src/checkpoint.rs: add Step 5 to verify_checkpoint_chain_with_weak_subjectivity binding the decoded queues to the terminal header's committed deltas — require checkpoint_state.get_added_validators(next_epoch) to equal terminal.added_validators() and checkpoint_state.get_removed_validators() to equal terminal.removed_validators() (order-normalized), rejecting mismatches with a new CheckpointVerificationError::CheckpointTransitionQueueMismatch.
• Document the inherent residual: pending additions for epochs beyond next_epoch (possible when validator warm-up spans more than one epoch) are committed by finalized headers after the terminal and cannot be authenticated by a chain ending at this epoch; they are bound only once the next epoch's boundary header is verified.
• Test: add test_checkpoint_verifier_binds_transition_queues_to_terminal_header (honest empty-queue checkpoint verifies; a checkpoint carrying a pending removed_validators entry while the terminal header commits an empty set is rejected, with hash/membership/position checks still passing). Parameterize checkpoint_verification_fixture with the checkpoint's removed_validators queue and update its callers.

[sebastian-osec]

I think the immediate transition check is correct, but I’m not sure we should accept future added_validators buckets as trusted checkpoint contents.

For a checkpoint at epoch N, the terminal finalized header authenticates removed_validators and added_validators[N + 1]. But ConsensusState.added_validators is a map, and entries for N + 2 or later are serialized inside the checkpoint and are not checked here.

Given VALIDATOR_NUM_WARM_UP_EPOCHS = 2, this seems reachable for normal deposits: a checkpoint at epoch N can carry added_validators[N + 2]. A malicious checkpoint could keep added_validators[N + 1] correct while choosing future additions, and Step 5 would still pass.

Could we either reject any added_validators entries beyond next_epoch, or explicitly document that future additions remain trusted checkpoint contents and are outside the fix for #216?

[matthias-wright]

Good point, I added a comment in types/src/checkpoint.rs to clarify this.