graph: Revert earliest_block off-by-one fix from #6340 (#6403)

The +1 introduced in fa6d677 broke two things for deployments
with history_blocks = reorg_threshold + 1:

- strategy() returned None (earliest_block == final_block), so
  pruning silently did nothing even though set_earliest_block had
  already advanced earliest_block_number in the database
- revert_block_ptr then failed for any reorg because
  earliest_block_number > ptr.number - reorg_threshold

Both revert_block_ptr and strategy rely on earliest_block < final_block,
which requires reorg_threshold + 2 actual blocks on disk. The old formula
(earliest_block = latest_block - history_blocks) keeps history_blocks + 1
blocks, providing exactly that buffer when history_blocks >= reorg_threshold + 1.

The copy_nonfinal_entities fix from 46367e7 is preserved.

Author: dimitrovmaksim

graph/src/components/store/mod.rs

@@ -1059,9 +1059,16 @@ impl PruneRequest {
             ));
         }
 
-        // We need to add + 1 to `earliset_block` because the lower bound is inclusive
-        // and otherwise we would end up with `history_blocks + 1` blocks of history instead of `history_blocks`
-        let earliest_block = latest_block - history_blocks + 1;
+        // Note: this intentionally keeps `history_blocks + 1` blocks on disk.
+        // The range [earliest_block, latest_block] is inclusive on both ends,
+        // so it contains `history_blocks + 1` entries. The extra block is a
+        // required buffer: `revert_block_ptr` requires at least
+        // `reorg_threshold + 2` actual blocks on disk to allow even a
+        // single-block reorg after pruning, and `strategy` requires
+        // `earliest_block < final_block`. Both conditions are satisfied when
+        // `history_blocks >= reorg_threshold + 1`, which gives
+        // `reorg_threshold + 2` blocks on disk.
+        let earliest_block = latest_block - history_blocks;
         let final_block = latest_block - reorg_threshold;
 
         Ok(Self {