[JasonVranek]

Builds on #635. Commit-Boost's ePBS bid stream, merged in commit-boost-client #509, is a client of this endpoint.

What this does

Before Gloas, a proposer client can open header_stream and receive the relay's improving bid until its deadline, instead of making one get_header request. Gloas replaces get_header with getExecutionPayloadBid, a POST, and has no stream. This PR adds the Gloas equivalent:

GET /eth/v1/builder/execution_payload_bid_stream/{slot}/{parent_hash}/{parent_root}/{proposer_pubkey}

The request upgrades to a websocket. Each time the top bid changes, the relay sends one binary frame, [kind = 1][fork = 7 (gloas)][ssz SignedExecutionPayloadBid], the same layout as the header stream. When the stream ends, the relay sends a close frame. Without it, a client cannot tell a stream that ended from one that failed.

A GET has no body, so the client sends its SignedBuilderRequestAuth in an X-Request-Auth header, as standard padded base64 of the ssz.

Admission

Every check runs before the upgrade, so a refused request gets an HTTP status and no socket opens. The cheap checks run first, and the BLS verify runs last:

• The slot must be a Gloas slot by the chain's fork schedule. The client's Eth-Consensus-Version header is not trusted for this.
• The same validate_header_request checks as header_stream: the slot being bid for, a registered proposer, timing.
• The path pubkey must be the slot's registered proposer. A wrong key is refused before any signature work.
• admit_header_stream decides whether this client may stream.
• X-Request-Auth is length-capped at the base64 size of the largest valid auth (5612 characters), then decoded.
• Last, the auth's slot and BLS signature are checked. This check is shared with the POST endpoint.

Implementation notes

• The first commit moves header_stream's schedule and polling loop into StreamSchedule, without behaviour changes, so both streams run the same loop. The second commit adds the bid stream on top.
• The bid stream reuses the header_stream config and admit_header_stream on purpose. An ApiProvider sees the same inputs for both streams and cannot tell PBS admission from Gloas admission, so the two streams share one admission policy.
• ExecutionPayloadBidStream joins the condensed ProposerApi route set, so a relay serving ProposerApi serves the stream. admit_header_stream still gates every connection.
• Each poll passes the bid the stream last sent. When the top bid has not changed, the auctioneer answers BidUnchanged without building or signing a bid.
• The auctioneer now returns the bid unsigned, and the API task signs it. This applies to the POST endpoint as well, so no BLS signature runs on the auctioneer thread. The POST's responses do not change. The bid reads prev_randao and gas_limit straight from the held payload instead of converting the whole payload to the Gloas shape. That conversion can only fail on extra_data over 32 bytes, which submission validation already refuses.
• The stream stops early when the auction has moved past the request: a later slot, a different proposer, or a payload already being delivered. It keeps polling when there is no bid yet, or when the auctioneer has not yet reached the requested slot.
• header_stream gets the same close frame in a separate change.

Tested

On a Gloas devnet running this branch (7d3fc65) and Commit-Boost 601b744 (main plus commit-boost-client #511), with every relay entry set to stream:

• Commit-Boost took the bid from the stream in every slot with a bid, 12 of 12, and sent no HTTP bid request.
• The relay ended all 12 no-bid streams with a close frame, and Commit-Boost answered 204 for each.
• This branch refused 7 of 7 malformed upgrades with a 4xx, and no socket opened.

Known limitation

The stream sends until the client's deadline, Date-Milliseconds + X-Timeout-Ms. getExecutionPayloadBid asks the builder to respond by that time, and the client discards anything later, so a frame sent in the last one-way network trip before the deadline arrives too late. If the one-way latency is longer than the streaming window (300 ms by default), no frame arrives in time at all. Ending the stream one return trip early would fix this, but the relay would first have to measure that trip, for example with a ping over the open stream. header_stream uses the same schedule and has the same gap, so both are left for a separate change.