fix(sync): cap data column range database batches

[exocognosis]

Problem

validateDataColumnsByRange preserves the full normalized request width in rangeParams.size. The shared blockRangeBatcher interprets that value as the slot width for each database lookup, so a request spanning thousands of slots can cause one large synchronous db.Blocks read before response quotas stop stream writes.

The block and blob range handlers already separate the full request range from the size of each database batch. The data column handler did not apply an equivalent bound.

Solution

• Preserve the normalized start and end slots so valid requests still cover their complete range.
• Clamp the per-read size to the configured block batch limit.
• Also bound the batch width by the fork-aware maximum block request size.
• Let the existing range batcher iterate across the remaining range in bounded database reads.
• Add regression coverage showing that a normalized 81-slot range uses the configured 64-slot batch size.
• Add the required changelog fragment.

Impact

This prevents large data column range requests from creating a single wide block database read. It does not reject valid requests, change their normalized range, or reduce the response quota. It only bounds the amount of block data loaded by each batch iteration.

Validation

• go test ./beacon-chain/sync -run '^TestValidateDataColumnsByRange$' -count=1
• go test ./beacon-chain/sync -count=1
• gofmt on the modified Go files
• git diff --check

Closes #17314

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}