cl: highest custody group count is not persisted across restarts

`fulu/validator.md` requires the highest custody group count a node has reached to survive a restart:

> The node SHOULD continue to custody and advertise the previous (highest) `custody_group_count`. [...] The previous (highest) `custody_group_count` SHOULD persist across node restarts.

Only the first half is enforced. `NewPeerDasState` initialises both `realCgc` and `advertisedCgc` to `beaconConfig.CustodyRequirement` (`cl/das/state/state.go:38-39`) with nothing read from disk, and the increase-only gate in `SetCustodyGroupCount` (`:62`) then keeps the value from being lowered *within* a process. So the ratchet holds while the node runs and resets on every start.

A node that had raised its count — validators attached, or a future explicit setting — comes back advertising `CustodyRequirement` again, and stops advertising groups it is still expected to custody and serve for the retention period. Peers that select column sources from the ENR will stop asking it for those columns.

Fixing it means persisting the highest advertised value and seeding `advertisedCgc` from it, rather than from `CustodyRequirement`. Where it lives is the open question — the caplin indexing DB is the obvious candidate, since the node key already persists under `datadir` for ENR stability across restarts.

Found while reviewing #23560, which seeds the ENR entry but deliberately leaves this alone: it predates that diff.

Read fulu/validator.md and cl/das/state/state.go, starting with NewPeerDasState and SetCustodyGroupCount. Then inspect the caplin indexing DB and existing datadir persistence used for the node key. Done means the highest advertised custody group count is restored after restart and is not lowered to CustodyRequirement.

Written by the indexing model from the issue text.