The per-block cap on distinct AttestationData is a transition rule in
leanSpec (`process_attestations`), and `fork_choice.on_block` says so
explicitly: "The transition itself bounds the distinct-data count. Only the
wire-level duplicate prohibition lives here."

We enforced it only at the import boundary in `on_block`, so
`state_transition()` accepted an over-cap block and then failed on the state
root instead. Both block production (`build_block` -> `process_block`) and
spec-fixture replay call the transition without going through `on_block`, so
neither was bounded.

Check it at the top of `process_attestations`, ahead of the
justification-bookkeeping guards as the spec does. The `on_block` check stays
for now: it runs before signature verification, so an over-cap block is still
rejected without paying for proof verification.

(leanSpec #536)

The per-block cap on distinct AttestationData is a transition rule in
leanSpec (`process_attestations`), and `fork_choice.on_block` says so
explicitly: "The transition itself bounds the distinct-data count. Only the
wire-level duplicate prohibition lives here."

We enforced it only at the import boundary in `on_block`, so
`state_transition()` accepted an over-cap block and then failed on the state
root instead. Both block production (`build_block` -> `process_block`) and
spec-fixture replay call the transition without going through `on_block`, so
neither was bounded.

Check it at the top of `process_attestations`, ahead of the
justification-bookkeeping guards as the spec does. The `on_block` check stays
for now: it runs before signature verification, so an over-cap block is still
rejected without paying for proof verification.

(leanSpec #536)

…ion (#555)

## What

Enforce the per-block cap on distinct `AttestationData` inside
`process_attestations`, where leanSpec has it, in addition to the
existing check at the import boundary in `on_block`.

## Why

leanSpec puts the bound in the transition
(`state_transition.process_attestations`) and `fork_choice.on_block`
defers to it explicitly:

> The transition itself bounds the distinct-data count. Only the
wire-level duplicate prohibition lives here.

We only had it in `on_block` (`store.rs`), so `state_transition()`
accepted an over-cap block and then failed on the state root instead.
Two callers reach the transition without passing through `on_block`:

| caller | before | after |
|---|---|---|
| `build_block` -> `process_block` | unbounded (the proposer-side clamp
is the only guard) | fails loudly instead of publishing an unimportable
block |
| spec-fixture replay / Hive `state_transition/run` | over-cap block
accepted, then `STATE_ROOT_MISMATCH` | rejected with the cap error |

The check goes first in `process_attestations`, ahead of the
justification-bookkeeping guards, matching the spec's order when a block
violates two rules at once.

## The duplicate check in `on_block` stays

Deliberately, for now: it runs before `verify_block_signatures`, so an
over-cap block is still rejected without paying for proof verification.
Whether we collapse the two sites into one is a follow-up decision.

## Testing

- `cargo test --workspace --profile release-fast`: green, no new tests
added here.
- The behavior is covered by the existing fixture
`test_block_exceeding_distinct_attestation_data_cap_rejects_block`,
which asserts failure but not yet the reason. Cross-checked against
#547, which adds the reason assertion to the fixture runners: with both
branches applied, that fixture passes for the right reason
(`TOO_MANY_ATTESTATION_DATA`, previously `STATE_ROOT_MISMATCH`).

Whichever of the two lands first, the other's exhaustive `From<&Error>
for RejectionReason` match makes the missing mapping arm a compile
error, so the reason cannot be silently dropped.

(leanSpec #536)