Compute real aggregate pubkeys when BLS verification is disabled

[nazarhussain]

Motivation

All fast_confirmation test vectors are generated with bls_setting: 2 (introduced in #5376 for generation speed). With BLS inactive, the pyspec stubs AggregatePKs via @only_with_bls(alt_return=STUB_PUBKEY), so it returns the constant 0x2222…22 instead of a real aggregate.

This is fine for signatures: bls_setting: 2 tells clients to skip signature verification, and they can honor that. The aggregate public key is different — it is data committed into the beacon state, not the result of a verification. At every sync committee rotation, get_next_sync_committee writes the AggregatePKs output into state.next_sync_committee.aggregate_pubkey. A client replaying such a vector computes the real aggregate during its state transition and arrives at a different state root, so block import fails with an invalid state root. No
real-crypto client can pass such a vector, and no bls_setting value can make it pass — the stub constant is effectively a generator-private convention. (Even a fake-crypto build wouldn't match: e.g. Lighthouse's fake_crypto
aggregate is the infinity pubkey, not 0x2222…22.)

Concretely, this breaks is_one_confirmed_fails_recently_activated_validator_voting_in_empty_slot (added in #5400), currently the only BLS-disabled test that runs long enough to cross a sync committee period boundary (slot 64 on minimal).

Change

Remove the only_with_bls stub from AggregatePKs so key aggregation is always computed for real, regardless of the BLS setting. Key aggregation is not signature verification, so it should not be gated on bls_active.

Validation

Regenerated is_one_confirmed_fails_recently_activated_validator_voting_in_empty_slot (electra/minimal) before and after the change: the anchor state and all files up to slot 63 are byte-identical; divergence starts exactly at slot 64 (the first sync committee rotation), where the real aggregate replaces the stub. The pyspec test itself passes unchanged, so FCR logic is unaffected — only the state roots change, to values that real-crypto clients can now reproduce.

[mkalinin]

I completely understand the motivation. We had this problem with compliance tests and the workaround we used in Teku was not computing but reading the aggregate_pubkey from the state.current_sync_committee.aggregate_pubkey in get_next_sync_committee, this would only work if there is 100% or less than 50% sync committee participation, because, otherwise, pubkey aggregation would be called in process_sync_aggregate with pubkeys that did not participate.

After proposed change there will be a slight increase in computations for get_next_sync_committee which is called once per 8 epochs with minimal preset. And also if participation is between 50% and 100% a similar computation will be happening each block, which should be specific to sync committee tests and shouldn’t affect compliance and FCR tests at all cause sync committee participation in these tests is 0.

Thanks for the proposed change!