fix: apply gossip clock disparity to proposer_preferences slot check

[lodekeeper]

Motivation

The Gloas proposer_preferences gossip validation [IGNORE] preferences.proposal_slot has not already passed compares proposal_slot against the exact current_slot. A preference whose proposal_slot falls within MAXIMUM_GOSSIP_CLOCK_DISPARITY of the next-slot boundary is accepted as valid when it should be ignored. The boundary is sub-slot (a 1 ms shift flips the outcome), so the integer current_slot comparison cannot express it.

This is the same class of gap fixed for the execution_payload_bid slot check in #9627.

Description

Use slotWithFutureTolerance(MAXIMUM_GOSSIP_CLOCK_DISPARITY / 1000) as the current_slot reference, matching the existing convention in verifyPropagationSlotRange (attestation.ts).

MAXIMUM_GOSSIP_CLOCK_DISPARITY is a global gossip allowance that applies even where the spec states the check as a plain preferences.proposal_slot > current_slot (as confirmed for the analogous bid check).

Verification

Ran the Gloas networking gossip reference tests from consensus-specs PR #5294:

• gossip_proposer_preferences__ignore_slot_outside_disparity → now ignore (was valid)
• gossip_proposer_preferences__valid_slot_at_disparity_edge → still valid
• gossip_proposer_preferences__valid_at_lookahead_upper_edge → still valid

Full gossip_proposer_preferences: 13/13 minimal + 13/13 mainnet, no regressions in the rest of the Gloas networking suite.

🤖 Generated with AI assistance

[gemini-code-assist]

Code Review

This pull request updates the proposer preferences validation to account for the maximum gossip clock disparity when checking if a proposal slot has passed. The reviewer suggested using the existing currentSlotWithGossipDisparity property on the clock to simplify the implementation and make it more idiomatic.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

Instead of manually calculating the tolerance and calling slotWithFutureTolerance, we can use the existing currentSlotWithGossipDisparity property on the clock. This property is specifically designed to handle the MAXIMUM_GOSSIP_CLOCK_DISPARITY check at slot boundaries, making the code cleaner and more idiomatic.

Suggested change

	const currentSlot = chain.clock.slotWithFutureTolerance(chain.config.MAXIMUM_GOSSIP_CLOCK_DISPARITY / 1000);
	const currentSlot = chain.clock.currentSlotWithGossipDisparity;

[lodekeeper]

Good call — applied in e75f482a60. currentSlotWithGossipDisparity is behaviour-equivalent here (both resolve to currentSlot, or currentSlot + 1 when within MAXIMUM_GOSSIP_CLOCK_DISPARITY of the next slot start) and drops the manual ms→s conversion. Biome clean.

[wemeetagain]

🎉 This PR is included in v1.45.0 🎉