Construct and sign the Gloas SignedExecutionPayloadEnvelope, and broadcast it to beacon nodes

[0w3n-d]

Issue: #489 (step 2 of 6)

Stacked on #501 — base branch is od/gloas-spec-link-cleanup, not develop. Retarget to develop once #501 merges.

What this PR does

• BeaconClient/MultiBeaconClient::publish_execution_payload_envelope: POSTs a SignedExecutionPayloadEnvelope to a connected beacon node's /eth/v1/beacon/execution_payload_envelopes, mirroring publish_block's fan-out-and-return-on-first-success.
• construct_signed_envelope: builds and signs the envelope from a proposer's signed block and a held payload, guarding against a missing held payload, a held-payload/bid block-hash mismatch, and a bid committing to a different builder_index than helix's configured identity.
• GloasBuilderIdentity: helix's own Gloas builder identity (builder_index + key), signing under DOMAIN_BEACON_BUILDER — not the off-chain domain SignedBuilderBid uses. Reuses the relay's existing signing key; builder_index is a new RelayConfig field, defaulting to 0 as a placeholder until helix has a real on-chain builder registration.
• Wires all of the above into submitSignedBeaconBlock: decodes the block, constructs and signs the envelope, and broadcasts it via MultiBeaconClient.
• NoHeldPayloads: the GloasPayloadStore implementation used until step 3 lands a real one. Every real request currently gets a NoHeldPayloadForBlock error, which is correct: nothing has held a payload yet.

What this PR deliberately does not do

No real held-payload store yet (step 3). No support for external builders submitting their own signed bids/envelopes (deferred, see the issue's resolved design question).

Tests

Written before wiring, per the issue's tests-first convention:

• BeaconClient::publish_execution_payload_envelope: correct headers/body, 200/202/error-response handling (httpmock).
• MultiBeaconClient::publish_execution_payload_envelope: returns on first success, errors only if all clients fail.
• construct_signed_envelope: correct construction, signature round-trip verification, and all three guard conditions.

Reviewer checklist

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