Single-shot WebSocket support with on-chain payments

[rickstaa]

What

Support single-shot WebSocket apps on-chain. A WS held-open session needs the same interval payment streamer as SSE, but the initial payment can't ride an inline 402 — you can't 402 a WS upgrade, and WS clients can't read the upgrade response headers.

Scope

• get_payment_params() — preflight call that fetches the 402 challenge (manifest_id, payment_params, orchestrator, payment_interval) over a plain HTTP request, so the client can pay before the upgrade.
• ws_connect helper — sets the initial payment headers (Livepeer-Payment / Livepeer-Segment / Livepeer-Payer-Address) on the upgrade request, opens the WS, starts the payment streamer, and stops it on close.
• Reuse the session-scoped streamer from Enable on-chain payments for single-shot streaming (SSE) sessions #42 (no new payment loop).
• End-to-end paid-WS test: preflight → paid upgrade through the single-shot proxy → metering over the connection lifetime → release on close.

Notes / dependencies

• Reuses the streamer and server metering from Enable on-chain payments for single-shot streaming (SSE) sessions #42 — the only WS-specific additions are the preflight and the ws_connect helper.
• Requires a go-livepeer preflight params affordance (a dedicated …/challenge endpoint is preferred over an implicit "GET returns 402"). Track on go-livepeer alongside #3955.
• Offchain single-shot WS already works (see the ja/live-runner ping-pong example); this issue is the on-chain path.

Part of the Live Runner: Single-Shot Pipelines project.

[linear-code]

ENG-180