cl/downloader: do not treat one empty block-range response as processed progress

## Problem

`ForwardBeaconDownloader.RequestMore` advances `highestSlotProcessed` to the end of a requested range when one peer returns an empty `BeaconBlocksByRange` response.

An empty response does not prove that the whole range contains only skipped slots. The peer may be faulty, incomplete, or malicious. `highestSlotProcessed` otherwise represents progress that passed the block-processing callback, so using it as a scan cursor mixes two different meanings.

## Impact

Forward sync can move its request window past canonical blocks that were never downloaded or processed. The overlap may hide some cases, but it does not make the progress claim valid. This can delay or stall sync and makes the stale-progress logic operate on an incorrect position. It does not directly import an invalid block.

## Expected behavior

Keep scanned-range progress separate from processed-block progress, or retry/corroborate an empty response before moving the request cursor. `highestSlotProcessed` should advance only from successful block processing.

The design must still traverse legitimate long ranges of skipped slots without repeatedly requesting the same range.

## Acceptance criteria

- A single empty range response cannot advance processed-block progress.
- Forward sync can continue scanning across genuine skipped-slot ranges.
- A regression test covers an empty response followed by a non-empty response for a block inside the previously empty range.

Start at ForwardBeaconDownloader.RequestMore and trace how BeaconBlocksByRange responses update highestSlotProcessed and advance the request window. Add a regression test for an empty response followed by a non-empty response within the prior range, while checking that genuine skipped-slot ranges still progress. Done means empty responses never advance processed-block progress and the regression test passes.

Written by the indexing model from the issue text.