fix(era-utils): fix off-by-one for Excluded end bound in process_iter

[Forostovec]

Previously, process_iter computed target = end + 1 for Bound::Excluded(end) and stopped on number > target, which allowed processing up to end + 1 and was incorrect, especially at u64::MAX. This change standardizes to an exclusive end bound: Included(end) becomes end.checked_add(1) (None on overflow), Excluded(end) becomes Some(end), and the loop exits on number >= end_exclusive. This fixes the off-by-one and aligns range handling with the rest of the codebase.

[mattsse]

unsure if this is right

@RomanHodulak wdyt?

[RomanHodulak]

@mattsse Upon checking this, the Excluded bounds mapping of the block_range actually have the saturating_sub and saturating_add calls flipped.

Like this:

    let mut last_header_number = match block_numbers.start_bound() {
        Bound::Included(&number) => number,
        Bound::Excluded(&number) => number.saturating_sub(1),
        Bound::Unbounded => 0,
    };
    let target = match block_numbers.end_bound() {
        Bound::Included(&number) => Some(number),
        Bound::Excluded(&number) => Some(number.saturating_add(1)),
        Bound::Unbounded => None,
    };

Should be:

    let mut last_header_number = match block_numbers.start_bound() {
        Bound::Included(&number) => number,
        Bound::Excluded(&number) => number.saturating_add(1),
        Bound::Unbounded => 0,
    };
    let target = match block_numbers.end_bound() {
        Bound::Included(&number) => Some(number),
        Bound::Excluded(&number) => Some(number.saturating_sub(1)),
        Bound::Unbounded => None,
    };

Because if you exclude a starting number, you have to start above the number and if you exclude a target number you have to stop below it.

We never encountered this because we haven't used the Excluded bounds yet. Nice catch! @Forostovec

This PR does not fix the last_block_header starting bound. I'm going to push a commit addressing this and then I think it's good to go.

[Forostovec]

@mattsse Upon checking this, the Excluded bounds mapping of the block_range actually have the saturating_sub and saturating_add calls flipped.

Like this:

    let mut last_header_number = match block_numbers.start_bound() {
        Bound::Included(&number) => number,
        Bound::Excluded(&number) => number.saturating_sub(1),
        Bound::Unbounded => 0,
    };
    let target = match block_numbers.end_bound() {
        Bound::Included(&number) => Some(number),
        Bound::Excluded(&number) => Some(number.saturating_add(1)),
        Bound::Unbounded => None,
    };

Should be:

    let mut last_header_number = match block_numbers.start_bound() {
        Bound::Included(&number) => number,
        Bound::Excluded(&number) => number.saturating_add(1),
        Bound::Unbounded => 0,
    };
    let target = match block_numbers.end_bound() {
        Bound::Included(&number) => Some(number),
        Bound::Excluded(&number) => Some(number.saturating_sub(1)),
        Bound::Unbounded => None,
    };

Because if you exclude a starting number, you have to start above the number and if you exclude a target number you have to stop below it.

We never encountered this because we haven't used the Excluded bounds yet. Nice catch! @Forostovec

This PR does not fix the last_block_header starting bound. I'm going to push a commit addressing this and then I think it's good to go.

Thanks for review