Investigate OpChainHardforks fork list validation

## Summary

Review comments from almanax-ai on PR #18825 flagged potential issues with `OpChainHardforks::new` in `alloy-op-hardforks`:

1. **Medium Severity**: `OpChainHardforks::new` stores an arbitrary `(OpHardfork, ForkCondition)` list and only sorts it, but later indexing (`Index`) assumes a dense, gap-free vector where `forks[fork.idx()]` corresponds to that exact variant.

2. **Low Severity**: The `Index::index` implementation unconditionally indexes `self.forks[]`, which could panic on missing/short fork lists.

3. **Low Severity**: Comment mismatch for Base Jovian timestamp

## Suggested Fixes

From the review comments:
- Validate and normalize the constructor input: either build a fixed-size array/vector indexed by `OpHardfork::idx()` and fill missing entries with `ForkCondition::Never`
- Or assert that `forks.len() == OpHardfork::VARIANTS.len()` and that each position's key matches the expected variant (and reject duplicates)
- Consider using `get()` for non-panicking indexing and returning `ForkCondition::Never` when the fork is absent

## Context

Related PR: #18825
Original comments:
- https://github.com/ethereum-optimism/optimism/pull/18825#discussion_r2699490214
- https://github.com/ethereum-optimism/optimism/pull/18825#discussion_r2699572290
- https://github.com/ethereum-optimism/optimism/pull/18825#discussion_r2714314714

Start with `OpChainHardforks::new` and the `Index` implementation in `alloy-op-hardforks`, then compare their assumptions with `OpHardfork::idx()` and `VARIANTS`. Review PR #18825 and its linked comments for the reported cases. Done means the accepted fork-list shape is explicit, missing or duplicate variants are handled consistently, indexing cannot panic unexpectedly, and the Base Jovian comment is reconciled.

Written by the indexing model from the issue text.