cl/sentinel, cl/phase1/forkchoice: serve req/resp chain data from fork_graph, not forkchoice

[domiwei]

What

Sentinel used only 7 of ForkChoiceStorageReader's 53 methods: 6 were one-line fork_graph re-exports, and the 7th (GetPeerDas) fetched a PeerDasStateReader that sentinel already receives at construction. This PR makes the dependency honest:

• New 6-method handlers.ChainDataReader interface (GetBlock, GetLightClientBootstrap, GetLightClientUpdate, NewestLightClientUpdate, HasEnvelope, ReadEnvelopeFromDisk), satisfied by fork_graph.ForkGraph. Sentinel, ConsensusHandlers and StartSentinelService take it instead of forkchoice.ForkChoiceStorageReader.
• Sentinel.Identity() reads the custody group count from the injected peerDasStateReader field instead of forkChoiceReader.GetPeerDas().StateReader() — same underlying object (run.go wires the same peerDasState into both), and it removes a nil-panic window between sentinel start and InitPeerDas.
• cl/sentinel no longer imports cl/phase1/forkchoice at all.
• Sentinel-side tests use a small map-backed ChainDataReaderMock instead of the 571-line ForkChoiceStorageMock.

Drive-by cleanup on surfaces this change already touches:

• Deleted interface/mock methods with zero external callers: JustifiedSlot (concrete method was also unused), ValidateOnAttestation and ShouldExtendPayload (concrete methods stay — used inside the forkchoice package), and the mock-only GetPublicKeyForValidator.
• Added a compile-time conformance assertion var _ forkchoice.ForkChoiceStorage = (*ForkChoiceStorageMock)(nil) so mock drift fails the build instead of a random test.

Why

The fork-choice interface is 64 methods wide and every consumer takes all of it; the hand-written mock has to model every method's semantics and has churned repeatedly as consumers hit unmodelled behavior. Narrowing sentinel to the 6 methods it actually uses shrinks its test surface accordingly and stops fork-choice interface growth from rippling into sentinel tests. This is the first slice of a larger consumer-role split of the fork-choice seam.

Explicitly not in this PR

• The 6 re-export methods stay on ForkChoiceStorageReader: cl/beacon/handler (and for some, cl/phase1/stages/cl/phase1/network) still call them through the fork-choice interface. Removing them requires migrating those consumers; note some sibling re-exports (AnchorRoot, AnchorSlot, LowestAvailableSlot) take f.mu.RLock() and are not pure pass-throughs, and the participation-indices pair converts blockRoot→epoch, so that migration needs care. Tracked separately.
• No behavior change intended anywhere.

Testing

Pure refactor — no new production behavior, so no new TDD cycle (per the repo's TDD pragmatism rules); the existing sentinel handler/request tests are the safety net and were migrated to the new mock. make lint clean (multiple runs), make erigon integration builds, go test -short ./cl/... ./cmd/caplin/... all green.