Key payload attributes and bids by parent hash and beacon root

[0w3n-d]

Issue: none. The bug came from a devnet report. Stacked on #587.

What this PR does

In Gloas, one (slot, parent_hash) can have two beacon roots. If N-1 is missed, the root is from N-2. If N-1 is empty, the root is from N-1. The relay kept only the first payload-attributes event. It then simulated and bid with the wrong root. Now the payload attributes and the bid sorter forks use a ForkKey key, which is (parent_hash, parent_root). A submission gets the fork that has the same prev_randao.

What this PR deliberately does not do

• It does not add an explicit parent_beacon_block_root to the submission. That is a change to the signed BidTrace, so it needs agreement with builders.
• It does not handle equivocation. If one proposer makes two empty N-1 blocks, both blocks have the same prev_randao, so the relay can select the wrong root.
• It does not change the builder's bid gate (schedule.rs, keyed on (slot, parent_hash)).
• Pre-Gloas get_header gets the fork from the parent hash only. Before Gloas, one parent hash has only one root.

Tests

• The housekeeper keeps two events that have the same parent hash and different roots.
• A submission gets the fork with the same prev_randao.
• get_execution_payload_bid liveness passes for each of the two roots on one parent hash.

I wrote the tests after the implementation.

Reviewer checklist

• CI (lint, unit-test) is green
• Matches the linked issue/step
• No unexplained scope creep or unrelated files touched

🤖 Generated with Claude Code

[0w3n-d]

Superseded by #635, which puts the unreviewed Gloas stack into one PR rebased onto develop.