fix(relay): handle WS errors during optimistic response streaming

[iceteaSA]

Summary

Fixes a bug where a relay-level WebSocket error arriving during an optimistic response that has already started streaming leaves the ReadableStream hanging indefinitely.

The problem

When optimisticResponse is true and response_start has already been received (resolving the pending promise with a streaming Response), a subsequent relay error message calls failPending(). But the promise is already resolved — the rejection goes nowhere, and the ReadableStream never gets closed or errored. The client hangs waiting for data that will never arrive.

The fix

Before falling through to failPending(), check if the optimistic response is already streaming (responseStartedAt != null). If so:

1. Inject an SSE error event into the stream (same pattern as the existing upstream-4xx handling in response_start)
2. Call finishPending() to close the stream cleanly
3. Close the socket

This matches the existing handling for upstream HTTP 4xx errors at line 792, extending it to relay-level errors that arrive mid-stream.

Testing

All 214 tests pass. This is a race condition that occurs when the relay server encounters an error after already forwarding the upstream's response_start — e.g., the worker hitting a CPU time limit mid-stream.