Fix shared slice mutation in fork schedule builder

[damilolaedwards]

Summary

ForkScheduleFromForkEpochs sorted its argument in place with sort.Slice. Since a slice argument shares its backing array with the caller, calling this read-shaped, innocuously named method reorders the caller's Spec.ForkEpochs out from under it, and races against anything else reading that slice concurrently, such as the fork metrics job that runs by default.

Fix sorts a copy instead, the same way BlobSchedule.GetMaxBlobsPerBlock already does.

Test plan

• Added tests in pkg/beacon/state/scheduled_fork_test.go: one confirming the caller's slice is no longer reordered, one running the builder concurrently against a reader using the same access pattern as ForkMetrics.calculateCurrent
• Confirmed both fail against the old code (mutation test fails outright, race test fails under -race) and pass against the fix
• go build ./..., go vet ./..., go test -race ./... all green