Wire submitBuilderPreferences to per-proposer per-slot storage on the auctioneer

[0w3n-d]

Issue: #489 (step 4 of 6)

Stacked on #507 — base branch is od/gloas-step3-execution-payload-bid. Retarget to develop once #501/#503/#507 merge.

What this PR does

• BuilderPreferencesStore: a (proposer_pubkey, slot) -> max_execution_payment map living on Context (not the per-slot-recycled SlotContext), since a proposer can submit preferences up to an epoch ahead of the slot they apply to -- entries must survive multiple slot transitions until their own slot arrives or passes. Pruned incrementally in Context::on_new_slot.
• New Event::SubmitBuilderPreferences, handled identically across all three auctioneer states (mirrors BuilderDemotion's existing all-states pattern) since storing a preference doesn't depend on what the auctioneer is currently doing.
• Rejects submissions for a slot that's already passed with the existing RequestForPastSlot error, reusing the same check the spec requires ("the builder MUST also reject...preferences whose auth.message.slot has already passed").
• The handler now calls through to the auctioneer instead of discarding the request after logging it.

What this PR deliberately does not do

Nothing reads from this store yet. getExecutionPayloadBid (step 3) never enforces max_execution_payment -- there's no real bid to enforce it against until step 5 lands real payload submission, so wiring the read side now would be dead code. That wiring is a small follow-up once step 5 lands.

Tests

• BuilderPreferencesStore (pure, no Context needed): stores and looks up per proposer per slot, resubmission overwrites the previous value, and on_new_slot prunes only entries for slots that have passed.

Reviewer checklist

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