fix(fork-choice): correct equivocation vectors' expected heads to the larger-root fork

[mananuf]

Fix the #1181 equivocation vectors that fail to generate at HEAD

Closes #1187.

At current main, fill --fork=lstar fails to generate three fixtures — the equivocation tests added in #1181 assert a head the fork-choice implementation does not produce:

FAILED test_equivocation.py::test_same_slot_equivocating_attesters_count_once      (head_slot 2, expected 3)
FAILED test_equivocation.py::test_equivocation_head_independent_of_arrival_order_a_then_b  (head_slot 3, expected 2)
FAILED test_equivocation.py::test_equivocation_head_independent_of_arrival_order_b_then_a  (head_slot 3, expected 2)

Root cause: the vectors, not the code

The three vectors hard-code which fork carries the larger attestation-data root and derive the expected head from that guess. But the concrete hash_tree_root ordering is scenario-dependent: test_same_slot uses 8 validators while the arrival-order tests use 6, which changes the genesis state root, hence the fork block roots, hence the vote-data roots. The docstrings guessed the ordering and guessed wrong.

The fork-choice code is correct: _extract_attestations_from_aggregated_payloads resolves an equal-slot tie toward the larger attestation-data root deterministically, and the property #1181 targets holds — a_then_b and b_then_a both produce the same head (fork_b, slot 3), independent of arrival order. The disagreements even go in opposite directions across tests (same_slot: actual fork_a vs asserted fork_b; arrival-order: actual fork_b vs asserted fork_a), which a direction bug in the code could not produce — it's the code computing the true per-scenario larger root while each vector guessed the wrong fork.

The fix

Correct the three vectors' expected heads (and docstrings) to the actual deterministic output — no spec-code change:

• test_same_slot_equivocating_attesters_count_once: head is fork_a (slot 2); V0/V1 count once toward fork_a (weights 3 vs 2).
• test_..._a_then_b / test_..._b_then_a: head is fork_b (slot 3), identical across both arrival orders — which is exactly the order-independence these tests exist to prove.

Verification

uv run fill tests/consensus/lstar/fork_choice/test_equivocation.py --fork=lstar --scheme=prod now generates all fixtures cleanly; the generated heads match (2, 3, 3). ruff format/ruff check pass.

Note

These tests remain sensitive to block-root ordering (inherent to hard-coding a hash-determined winner) — a future change to block building could flip the concrete winner again. Happy to follow up with a more robust formulation (e.g. asserting the equivocator-counted-once and order-independence invariants without pinning the absolute fork) if preferred.

[mananuf]

Closing this — the fix is incorrect, and the root cause turned out to be scheme dependence, not a code-vs-vector mismatch.

CI (fill --fork=Lstar, default test scheme) produces heads that are the exact opposite of what I saw when reproducing/validating under --scheme=prod (the scheme our downstream client uses for real-XMSS fixtures):

test	test scheme (CI)	prod scheme
same_slot	fork_b (3)	fork_a (2)
a_then_b / b_then_a	fork_a (2)	fork_b (3)

Different scheme → different validator keys → different genesis state_root → different block roots → different attestation-data roots → the equal-slot tie-break (larger attestation-data root) resolves to the opposite fork. The fork-choice code is correct and deterministic under each scheme; the vectors' hard-coded heads simply can't be valid for both.

So the existing vectors are correct for the canonical test scheme, and this PR's hard-coded prod values break the test-scheme CI. Reverting would leave an empty PR, so closing. I've corrected #1187 with the accurate analysis — apologies for the noise.