Track pruning policy for Gloas execution payload envelopes

## Background

From the Discord archive-node-support discussion: if Lodestar wants bounded historical storage, Gloas execution payload envelopes need an explicit retention policy too.

Current `unstable` check: `9ba9a5ce85` (2026-09-01).

`archiveBlocks()` currently prunes expired archived blobs and data column sidecars using `archiveDataEpochs` plus the spec minimum request windows:

- `blobSidecarsArchive`: `max(MIN_EPOCHS_FOR_BLOB_SIDECARS_REQUESTS, archiveDataEpochs)`
- `dataColumnSidecarArchive`: `max(MIN_EPOCHS_FOR_DATA_COLUMN_SIDECARS_REQUESTS, archiveDataEpochs)`

It also migrates Gloas execution payload envelopes from hot DB to `executionPayloadEnvelopeArchive`, but there is no corresponding expiry/prune path for that archive bucket.

`--chain.pruneHistory` is also currently limited to old `blockArchive` and `stateArchive` entries, so enabling history pruning still leaves archived payload envelopes out of scope.

Relevant code:

- `packages/beacon-node/src/chain/archiveStore/utils/archiveBlocks.ts`
- `migrateExecutionPayloadEnvelopesFromHotToColdDb()`
- blob/data-column archive pruning blocks
- `packages/beacon-node/src/chain/archiveStore/utils/pruneHistory.ts`
- `packages/beacon-node/src/network/reqresp/handlers/executionPayloadEnvelopesByRange.ts`
- `packages/beacon-node/src/network/reqresp/handlers/executionPayloadEnvelopesByRoot.ts`

## Why this matters

Post-Gloas, payload envelopes are needed for historical payload-envelope req/resp serving. If we retain them forever while pruning blobs/columns/blocks according to bounded windows, Gloas nodes can accumulate unbounded historical payload-envelope data.

This also intersects with the archive-node policy question from the thread:

- Do regular nodes keep only spec-required request windows?
- Do nodes that support syncing from genesis need to serve old payload envelopes too?
- If `--chain.archiveDataEpochs` and/or `--chain.pruneHistory` are removed or changed, what is the intended payload-envelope retention behavior?

## Suggested scope

- Decide the intended retention policy for `executionPayloadEnvelopeArchive`.
- Add pruning for archived execution payload envelopes, likely in the same finalization/archive flow that prunes archived blobs and columns, or in `pruneHistory` if it should track block history retention.
- Make the policy consistent with `ExecutionPayloadEnvelopesByRange` / `ExecutionPayloadEnvelopesByRoot` serving semantics and `earliestAvailableSlot`.
- Add focused archive-store tests covering payload-envelope archive pruning.
- Update CLI/docs if `archiveDataEpochs` / `pruneHistory` behavior changes.

## Open question

Should archived payload envelopes follow the block history window (`MIN_EPOCHS_FOR_BLOCK_REQUESTS`) or the DA retention window (`archiveDataEpochs` / sidecar minimums), or do we need a separate policy for genesis-sync/archive-node support?

Start by reading packages/beacon-node/src/chain/archiveStore/utils/archiveBlocks.ts and pruneHistory.ts, then inspect the executionPayloadEnvelopesByRange.ts and executionPayloadEnvelopesByRoot.ts handlers. Trace the existing archive and earliestAvailableSlot behavior before deciding which retention window applies. Done means the policy is agreed, archive pruning and focused tests cover it, and any CLI or documentation changes are included.

Written by the indexing model from the issue text.