cl/phase1/network/services: reuse pendingJobQueue for Gloas data-column sidecars

## Problem

Once #22177 lands, three Gloas gossip services will share `pendingJobQueue`, but `dataColumnSidecarService` will still maintain the same lifecycle separately with a `sync.Map`, atomic count, expiry ticker, and manual removal.

The current sidecar admission path checks the count before `LoadOrStore` and increments it afterward. Concurrent unique enqueues can therefore pass the check together and admit more than `maxPendingGloasSidecars`. Removal also uses unconditional `Delete` plus a separate decrement instead of identity-checked removal.

There is no known production incident. This is adjacent technical debt and a chance to make the configured cap reliable under concurrency.

## Proposed change

Use `pendingJobQueue` for Gloas data-column sidecars, with a queued value that retains both the sidecar and subnet:

- key: `(beacon_block_root, index)`
- capacity: 4096
- expiry: 24 seconds
- check interval: 500 milliseconds

Preserve the existing service policy:

- duplicates are silent no-ops;
- expired and finalized-slot sidecars are removed;
- sidecars remain queued while their block is unavailable;
- validation runs before removal once the block arrives;
- `ErrIgnore`, logging, and context-cancellation behavior remain consistent.

The expiry callback currently logs the sidecar slot as well as its key. If the shared callback needs the queued value to preserve that context, extend the callback deliberately rather than adding the slot to the key, because changing the key would change deduplication semantics.

## Tests

Add focused characterization tests before the refactor for:

- duplicate admission;
- expiry;
- finalized-slot removal;
- retention while the block is unavailable;
- processing and removal after the block arrives;
- background-loop cancellation.

Add a failing concurrent-cap test first, then make it pass with the shared queue. Run the service tests under the race detector.

## Acceptance criteria

- Stored pending sidecars never exceed `maxPendingGloasSidecars`, including under concurrent admission.
- The sidecar queue uses the shared lifecycle implementation from #22177.
- Existing validation and consensus `IGNORE`/`REJECT` behavior is unchanged.
- The focused package tests and race detector pass.