Verify proof APIs after Gloas

## 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.

Start by locating the existing proof API implementations and their tests, then compare their assumptions with post-Gloas state and block types and the EIP-7688 generalized-index and multiproof expectations. Done means pre- and post-Gloas behavior is verified with tests, and any consumer-format or beacon-APIs specification gaps are documented or tracked.

Written by the indexing model from the issue text.