params: mark amsterdam blob-schedule entry as optional (#34833)

## Summary

Marks `amsterdam` as `optional` in the blob-schedule fork-validation
table in `params/config.go::CheckConfigForkOrder`, so that a chain
config setting `amsterdamTime` no longer requires a corresponding
`blobSchedule.amsterdam` entry to be present.

## Why

Hive's `clients/<el>/mapper.jq` removed the `amsterdam` block from the
generated `blobSchedule` in
[ethereum/hive#1387](https://github.com/ethereum/hive/pull/1387)
("Remove Amsterdam blob param defaults — values are wrong; we agreed to
remove named forks from blob config").

With strict validation in place, every hive simulator that activates
Amsterdam — including `ethereum/eels/consume-engine` against
`bal-devnet-4` — now fails immediately at `geth init`:

```
Fatal: Failed to write genesis block: invalid chain configuration:
missing entry for fork "amsterdam" in blobSchedule
```

This shows up in the latest scheduled CI runs of
[ethpandaops/hive-tests](https://github.com/ethpandaops/hive-tests) as a
flood of `"could not start client … terminated unexpectedly"` errors on
Amsterdam tests (the simulator job is marked "success" only because the
simulator process itself completes — `tests=46285 failed=24369`).

The `bal-devnet-3` branch already carried a relaxation for the same
reason (commit
[`265d74b75`](https://github.com/ethereum/go-ethereum/commit/265d74b75)
commented the entire check out). This change is narrower:
- only `amsterdam` is marked optional,
- every other fork (`cancun`, `prague`, `osaka`, `bpo1..bpo5`) keeps its
strict check,
- `cur.config.validate()` still runs whenever a caller *does* supply a
blob entry, so misconfigured Amsterdam blob params remain rejected.

It also matches the pattern already used in the fork-ordering table just
above, where `amsterdam` and the BPO timestamps are likewise marked
`optional: true`.

## Test plan

- `go build ./...` and `go test ./params/...` pass locally.
- Reproduced the original failure: a freshly-built
`ethpandaops/geth:bal-devnet-4` errors at `geth init` on a genesis with
`amsterdamTime` set but no `blobSchedule.amsterdam`. With this patch
applied, the same `geth init` succeeds and writes the genesis state.
- Suggest re-running `ethpandaops/hive-tests` workflow
`hive-devnet-4.yaml` against this branch (`common_client_tag:
qu0b/relax-amsterdam-blobschedule-validation`, `client_source: git`) to
confirm Amsterdam tests start the client cleanly.

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

params/config.go

@@ -999,6 +999,7 @@ func (c *ChainConfig) CheckConfigForkOrder() error {
 		name      string
 		timestamp *uint64
 		config    *BlobConfig
+		optional  bool
 	}{
 		{name: "cancun", timestamp: c.CancunTime, config: bsc.Cancun},
 		{name: "prague", timestamp: c.PragueTime, config: bsc.Prague},
@@ -1008,14 +1009,14 @@ func (c *ChainConfig) CheckConfigForkOrder() error {
 		{name: "bpo3", timestamp: c.BPO3Time, config: bsc.BPO3},
 		{name: "bpo4", timestamp: c.BPO4Time, config: bsc.BPO4},
 		{name: "bpo5", timestamp: c.BPO5Time, config: bsc.BPO5},
-		{name: "amsterdam", timestamp: c.AmsterdamTime, config: bsc.Amsterdam},
+		{name: "amsterdam", timestamp: c.AmsterdamTime, config: bsc.Amsterdam, optional: true},
 	} {
 		if cur.config != nil {
 			if err := cur.config.validate(); err != nil {
 				return fmt.Errorf("invalid chain configuration in blobSchedule for fork %q: %v", cur.name, err)
 			}
 		}
-		if cur.timestamp != nil {
+		if cur.timestamp != nil && !cur.optional {
 			// If the fork is configured, a blob schedule must be defined for it.
 			if cur.config == nil {
 				return fmt.Errorf("invalid chain configuration: missing entry for fork %q in blobSchedule", cur.name)