Add SSZ response support for validator_balances endpoints

[Zyra-V21]

What

Adds an application/octet-stream (SSZ) response to GET and POST /eth/v1/beacon/states/{state_id}/validator_balances, selectable via the
Accept header, plus a 406 Not Acceptable matching the other SSZ-enabled
state endpoints (validator_identities, pending_partial_withdrawals).

The SSZ payload is List[ValidatorBalanceResponse, VALIDATOR_REGISTRY_LIMIT],
each entry being the container { index: uint64, balance: uint64 }. It is
purely additive: no JSON changes, no new parameters, JSON consumers are
untouched.

Context

Split out of #601 per the discussion there (cc @nflaig, @etan-status,
@lodekeeper). validator_balances has no status and no enum, so the SSZ
enum questions raised for the validators endpoint do not apply here. The
validators side stays at status quo for now; this is the uncontroversial
half.

Already shipping

This documents behavior clients already serve. Lodestar has returned SSZ on
this endpoint since ChainSafe/lodestar#6749 (v1.20.0, around two years), with
the same {index, balance} shape (confirmed by @lodekeeper in #601). Adding
SSZ to an existing endpoint is backward compatible via Accept header content
negotiation.

The concrete consumer is analytics/indexing: MigaLabs' goteth snapshots
balances per processed epoch and backfills large historical ranges, where the
JSON encode/parse cost on both ends is the bottleneck (gzip cuts wire size but
not that CPU). SSZ reduces both.

Validation

redocly lint ./beacon-node-oapi.yaml is valid and swagger-cli bundle
succeeds, matching the CI.

Tests

The spec is validated by lint + bundle rather than a test suite, so there is
no test harness to extend here. If you would like anything beyond that (an
example payload, or a client conformance check), say so and I will add it.

Related: #601, #333.

[lodekeeper]

LGTM from the Lodestar side — and I can confirm this matches what Lodestar already serves, so it's really just documenting existing behavior (which was the point of splitting it out of #601 👍).

• SSZ schema matches Lodestar exactly. List[ValidatorBalanceResponse, VALIDATOR_REGISTRY_LIMIT] with ValidatorBalanceResponse = {index: uint64, balance: uint64} is exactly what Lodestar has returned since #6749 (v1.20.0) — List[Container{index: ValidatorIndex, balance: UintNum64}], both uint64. So indexers already get this wire format from Lodestar today.
• Additive + backward-compatible as intended: JSON response unchanged, SSZ opt-in via Accept, and the 406 NotAcceptable on both GET and POST is correct (the $ref resolves — beacon-node-oapi.yaml#/components/responses/NotAcceptable).
• Matches house style — the application/octet-stream description follows the sibling state-list endpoints (pending_consolidations, proposer_lookahead, pending_partial_withdrawals); the extra "Each ValidatorBalanceResponse is the SSZ container {index, balance}" line is a helpful clarification since the JSON schema uses string-encoded uints.

One minor nit (non-blocking): the two new CHANGES.md rows are missing the [#622](https://github.com/ethereum/beacon-APIs/pull/622) PR-link prefix that every other row in that table carries — worth adding for consistency.

Thanks for splitting this out!

[Zyra-V21]

Sure, will fix that soonish

[nflaig]

LGTM, thanks @Zyra-V21 for working on this, it's long overdue to add this to the spec, we've already implemented ssz response for this endpoint ~2 years ago.

[rolfyone]

LGTM