fix: treat fork schedule init failures as fatal config errors

[Bashmunta]

What type of PR is this?

Feature

What does this PR do? Why is it needed?

InitializeForkSchedule now returns an error instead of logging and continuing when NetworkSchedule.prepare fails. All config constructors and helpers that build BeaconChainConfig (mainnet, minimal, interop, testnets, E2E configs) now panic on initialization failure to surface invalid fork schedules as hard configuration errors. configset.add, OverrideBeaconConfig, and YAML config loading handle the new error-returning API and either propagate or fail fast. Tests that relied on InitializeForkSchedule were updated to assert require.NoError, and E2E helpers now abort the test when fork schedule initialization fails.

Acknowledgements

• I have read CONTRIBUTING.md.
• I have included a uniquely named changelog fragment file.
• I have added a description with sufficient context for reviewers to understand this PR.
• I have tested that my changes work as expected and I added a testing plan to the PR description (if applicable).

[CLAassistant]

All committers have signed the CLA.

[kasey]

Thanks for the contribution! I agree that this method should return an error rather than logging, however I believe the use of panic in this PR pushes the problem around and avoids the tedious refactoring I had in mind when writing the TODO. We are trying to avoid introducing more instances of panic where possible, and I believe that is possible on the config init path. Instead of using panic we would like to propagate errors all the way back to program startup / test handlers (in the case of eg OverrideBeaconConfig). It's not a fun task but if it's something you would like to take on I can support with reviews.

[Bashmunta]

Thanks for the contribution! I agree that this method should return an error rather than logging, however I believe the use of panic in this PR pushes the problem around and avoids the tedious refactoring I had in mind when writing the TODO. We are trying to avoid introducing more instances of panic where possible, and I believe that is possible on the config init path. Instead of using panic we would like to propagate errors all the way back to program startup / test handlers (in the case of eg OverrideBeaconConfig). It's not a fun task but if it's something you would like to take on I can support with reviews.

Thanks for review, I'm gonna re-review my changes and will avoid panics