Update Schema Registry and adopt progressive ssz in GLOAS

[tbenr]

fixes #10930
fixes #10931

PR Description

Fixed Issue(s)

Documentation

• I thought about documentation and added the doc-change-required label to this PR if updates are required.

Changelog

• I thought about adding a changelog entry, and added one if I deemed necessary.

---

Note

High Risk
Large consensus-layer schema and Gloas state-upgrade changes affect merkleization, fork transitions, and networking limits; incorrect rematerialization or progressive list wiring could break interoperability at the Gloas fork.

Overview
This PR wires Gloas to progressive SSZ (EIP-7916): bounded block-body and execution lists become SszProgressiveListSchema, Gloas containers use active field masks, and blob/data-column schemas split into milestone-specific types (e.g. BlobKzgCommitmentsSchemaGloas, DataColumnSchemaGloas) behind shared interfaces.

Schema registry usage expands so transactions, deposit/execution-request lists, aggregation bits, and similar types are resolved from the registry instead of being built inline with config max lengths. DepositProvider drops its local deposits schema cache and uses getDepositsSchema() from slot schema definitions. Execution payload schemas take SchemaRegistry and expose SszByteListSchema<Transaction> (plus ProgressiveTransactionSchema for Gloas).

Gloas fork transition rematerialises list fields when merkleization changes via BeaconStateListFieldMigration (SSZ round-trip) and copyCommonFieldsFromSourceUsingTargetSchemas. BeaconStateSchemaGloas and common validators/balances fields use progressive lists at Gloas+.

Networking/config: Gloas adds payload size constants and optional networkSszLengthBytesUpperBound on several gossip types. Light client gets LightClientBootstrapSchemaGloas with a Gloas sync-committee gindex. DelegatingSpecConfigElectra.getMaxAttestations() now returns the Electra cap.

^{Reviewed by Cursor Bugbot for commit d556f14. Bugbot is set up for automated code reviews on this repo. Configure here.}

[rolfyone]

mixed bag from claude here so i'll just post its output

Missing coverage:

• No test for the EXECUTION_PAYLOAD_SCHEMA → EXECUTION_PAYLOAD_HEADER_SCHEMA registry dependency (item 1 above).
• No round-trip test for BLOCK_ACCESS_LIST in ExecutionPayloadGloasImpl (item 3 above).
• No test asserting historical_summaries stays bounded in the Gloas state schema and that direct assignment still works after upgrade (item 2 above).
• BeaconStateListFieldMigration.toTargetList/toTargetUInt64List have no standalone unit tests. These are critical migration paths; they're covered implicitly by GloasStateUpgradeTest but an isolated test with a bounded→progressive migration
  assertion would be valuable.

Good coverage added:

• PooledAttestationWithDataTest for the cross-fork bitlist adaptation
• AttestationGloasSchemaTest for progressive schema type assertions
• NetworkSszLengthBoundsTest for the five GLOAS network-bound schemas
• ProgressiveTransactionSchemaTest for the new schema
• GloasStateUpgradeTest.shouldRematerializeEpochParticipationWithUInt8Schemas

---

Minor

• gnosis.yaml only adds MAX_REQUEST_PAYLOADS: 128 at the chain-config level; the four MAX_*_SIZE constants are correctly in the per-preset presets/gnosis/gloas.yaml. Verified consistent.
• GloasBuilder.addOverridableItemsToRawConfig now populates the four new constants — consistent with getValidationMap().
• Java 25 unnamed parameters (_) and the @SuppressWarnings("JavaCase") on SchemaRegistryBuilder is a pragmatic workaround. Add a TODO comment with the Error Prone issue number so it gets removed once the tool is updated.

---

Summary

The overall approach is correct and follows established patterns. The most important items to address before merge are:

1. Confirm or add a test for the registry resolution ordering (payload header → payload schema cross-dependency)
2. Resolve the historical_summaries inconsistency (comment says bounded, upgrade rematerializes it)
3. Add a Gloas execution payload round-trip test covering BLOCK_ACCESS_LIST

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Reviewed by Cursor Bugbot for commit f3c61bb. Configure here.}