Socket close mid-stream is treated as a completed response

ai slop but still true:

**Describe the bug**

When the WebSocket closes mid-stream, `WebSocketChatTransport` ends the response stream with `controller.close()` instead of `controller.error(...)`. The AI SDK treats that as a normal completion, so a dropped connection is indistinguishable from a finished answer.

```js
// agents@0.20.1 dist/chat/react.js:255-257
const onClose = () => {
finish(() => controller.close(), false, false);
};
```

The same pattern appears again at `:473`. Compare `:245`, where an explicit error frame correctly calls `controller.error(new Error(data.body || "Stream error"))`.

The user is left with a silently truncated assistant message: no error state, no retry affordance, and nothing marking the response as incomplete. `isLoading` clears as if the turn succeeded.

**To Reproduce**

Steps to reproduce the behavior:

1. Start a chat turn with `useAgentChat` that streams a long assistant response.
2. While the response is still streaming, drop the WebSocket (kill the network, or close the socket from devtools).
3. Observe the partial assistant message.
4. See that the stream resolves cleanly — no `onError`, no error state, and the truncated message is presented as a completed answer.

**Expected behavior**

A socket close during an in-flight stream should surface as an error, the same way an explicit error frame does, so the UI can show that the response was interrupted and offer a retry.

**Screenshots**

N/A.

**Version:**

`agents@0.20.1`. Also present in `0.19.0`.

**Additional context**

We patch this locally to `finish(() => controller.error(new Error("Chat connection interrupted")), false, false)`, which restores the expected error state.

This is distinct from #1898, which covers terminal `error: true` frames in the React observer path. This one is the transport's socket-close handler, where no frame arrives at all.