Single-shot WebSocket support with on-chain payments

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 #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 #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.

Start by reviewing the session-scoped streamer and server metering from #42, then compare the existing offchain single-shot WebSocket flow in the ja/live-runner ping-pong example. Confirm the go-livepeer preflight params affordance tracked with #3955 before implementing the preflight and upgrade path. Done means the paid-WS end-to-end test covers preflight, paid upgrade, metering, and release on close.