cl/blob_storage: pruning rejects writes inside the non-archive backfill window

## Problem

Blob cleanup uses a fixed retention distance of 128,600 slots, while the non-archive blob history downloader scans back to `BeaconChainConfig.MinSlotsForBlobsSidecarsRequest()`.

The configured downloader windows are:

- mainnet: `4096 * 32 = 131072` slots
- Gnosis and Chiado: `16384 * 16 = 262144` slots

After cleanup calls `BlobStore.PruneBelow`, `bucketStore.startWrite` rejects every write whose slot is below the pruning floor. `WriteBlobSidecars` returns `nil` for that rejection.

As a result, slots in `[currentSlot - configuredWindow, currentSlot - 128600)` are selected for non-archive backfill but cannot be persisted. The durable post-check finds the sidecars missing and retries them until they age out of the downloader window.

## Impact

- On mainnet, the bottom 2,472 slots of the advertised backfill window cannot be repaired after the pruning floor advances.
- On Gnosis and Chiado, the affected range is 133,544 slots.
- The rejected write returns no error, so logs do not identify the retention mismatch as the cause.
- Immediate blob backfill can remain incomplete while repeatedly fetching data that storage will not accept.

This is present on `main` and is inherited by the release/3.6 backport in #23732.

## Suggested fix

Use one chain-configured retention boundary for both pruning and non-archive backfill. If the protocol window is the intended retention policy, derive the pruning distance from `MinSlotsForBlobsSidecarsRequest()`. If 128,600 slots is intentional, clamp the downloader to that same boundary instead.

Add an integration test that advances the storage pruning floor and then backfills a missing sidecar near the lower edge of the configured downloader window.

Related retention tracking: #23024. Related missing-sidecar consequences: #23224.