Sign the built block and submit it to the relay

[0w3n-d]

Issue: #550 (step 4 of 6)

What this PR does

Signs each built block and POSTs it to the relay as SSZ. The builder is now
functionally complete: it watches slots, builds, pays the proposer, signs and
submits. Step 5 only adds in-slot timing and the optional self-check.

The conversion chain reuses what already exists — block_to_payload_v3 ->
payload_from_v3, requests_to_v4 -> requests_from_v4. Only the blobs
bundle is new, as the inverse of convert::eblobs.

Two details worth review:

• The builder domain comes from the beacon node, through
  BeaconClient::get_chain_info() reading eth/v1/config/spec and
  eth/v1/beacon/genesis. No hardcoded per-network fork versions. Getting this
  wrong makes the relay drop every bid with no useful error, so the role fails
  at startup rather than signing incorrectly.
• The blobs bundle is checked by proof count, not by version. ethrex's
  impl AddAssign for BlobsBundle does not propagate version, so an
  aggregated bundle always reports 0 even when its sidecars carry EIP-7594 cell
  proofs. The count of 128 per blob is the only trustworthy signal, and
  helix_types::BlobsBundle refuses to decode without it.

Every BidTrace field the relay cross-checks is read back off the converted
payload rather than from the build, so the two cannot drift.

What this PR deliberately does not do

One submission per slot event, at the moment the event arrives — no timing
offsets, no resubmission on a higher value, and no self-validation. Those are
step 5, which is why submit_offsets_ms and self_validate are still unread.
No optimistic v3, no bid adjustments, no multi-relay fan-out.

Tests

12 new, written before the implementation and signed off first.

• Blobs (4): a cell-proof bundle converts; a bundle with one proof per blob is
  refused; mismatched commitments are refused; an empty bundle converts.
• The submission (5): the BidTrace mirrors the payload on the four fields
  payload.validate() checks; it carries the slot and proposer; the
  signature verifies under the builder domain, using verify_signature —
  the same call the relay's decoder makes; the submission round-trips through
  SSZ, with and without a blob.
• HTTP (3), against a small axum stub on an ephemeral port: the request carries
  application/octet-stream and X-Api-Key; a 2xx is success; a 400 surfaces
  the relay's message, since that text is how an operator learns the builder
  is producing bad blocks.

139 pass in the crate.

Reviewer checklist

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