Keep block period on the current epoch during resync

[Frozen]

Summary

• compute BlockPeriod from the current epoch during startup and mid-epoch resync
• switch to the next epoch cadence only for consensus following the last block of the current epoch
• schedule NextBlockDue and a newly rotated leader with that next-consensus cadence
• cover both 5s-to-2s and 2s-to-1s activation boundaries

Root cause

updateConsensusInformation always checked nextEpoch when selecting BlockPeriod. A validator that restarted or resynced during the epoch immediately before a timing fork therefore adopted the faster cadence one epoch early.

The first implementation corrected resync but exposed an ordering issue at epoch boundaries: NextBlockDue and the rotated-leader delay could capture the old period before consensus information was updated. The final change derives the period from the epoch of the consensus being scheduled.

Behavior

• startup/resync within an epoch uses currentEpoch
• consensus after a non-final block keeps the current cadence
• consensus after the last block uses nextEpoch
• the first block at 5s-to-2s and 2s-to-1s activation is scheduled with the new cadence

[Test]

• go test -mod=readonly ./consensus/... -count=1
• go test -mod=readonly -race ./consensus -run '^(TestBlockPeriodForConsensusUpdate|TestSetNextBlockDueUsesPeriodForNextConsensusEpoch)$' -count=1
• go vet -mod=readonly ./consensus/...
• make test
• git diff --check
• independent consensus-sensitive review: passed; no security, logic, race, aliasing, or consensus-regression findings

[greptile-apps]

Your trial has ended. Reactivate Greptile to resume code reviews.

[greptile-apps]

Your trial has ended. Reactivate Greptile to resume code reviews.