Verify proof APIs after Gloas

[lodekeeper]

Context

Rocket Pool appears to rely heavily on Lodestar beacon proof APIs. Before Gloas support is considered production-ready, we should explicitly verify that those APIs still return correct/protocol-useful proofs across the Gloas state and block restructuring.

This is especially worth checking because Gloas changes execution payload handling, introduces new post-Gloas block/state shapes, and EIP-7688 affects generalized-index / multiproof expectations.

Original prompt from Discord: Rocket Pool relies on our proof APIs; do we know if they still work correctly with Gloas?

What to check

• Audit the existing proof API implementations for fork-specific assumptions that may break at or after the Gloas fork.
• Verify all proof endpoints against post-Gloas state/block types, including any changed generalized indices from EIP-7688.
• Add or update tests for pre-Gloas and post-Gloas behavior, preferably covering the fork boundary where practical.
• Confirm whether the multiproof format expected by consumers is formally specified anywhere. If not, decide whether Lodestar should document its behavior and/or propose it for beacon-APIs.
• Check whether beacon nodes should be expected/required to support these proof APIs for external consumers, and if so, track any required beacon-APIs spec work.

Notes

This is a compatibility and ecosystem-support issue, not a confirmed bug yet. The goal is to avoid silently breaking downstream consumers as Gloas lands.