fix: propagate SSE errors as stream terminations instead of silent parts

[danielxxomg]

Summary

Changes SSE error handling so that error events and network read failures terminate the stream via controller.error() instead of being silently enqueued as {type: "error"} stream parts.

Depends on: PR #10 (retry/backoff core) — this PR is stacked on top of it.

Problem

When the Command Code API emits an SSE error event or the network connection drops mid-stream, the original code enqueues the error as a stream part:

// Before (silent — AI SDK never sees the failure)
controller.enqueue({ type: "error", error: event.error ?? ... })

The AI SDK treats {type: "error"} as just another content part and never triggers its own error handling or retry logic. The stream completes "successfully" with an error buried in the content.

Solution

// After (real termination — AI SDK sees the failure)
controller.error(wrapError(event.error ?? ...))

src/stream.ts (188 → 243 lines)

• wrapError() — normalizes SSE error objects (which are plain objects, not Error instances) into real Error objects with proper stack traces
• SSE error events → controller.error(wrapError(...)) — terminates the stream
• Network read failures → controller.error(wrapError(...)) — terminates the stream
• Removed silent {type: "error"} stream part handling entirely

Tests

• 6 new + 1 updated tests in tests/unit/stream.test.ts
• 23 stream tests passing, 88 total tests passing

Why This Matters

Combined with PR #10's retry logic, this creates a clean error propagation chain:

SSE error event
  → controller.error() (this PR)
    → streamWithReconnect catches it (PR #10)
      → shouldRetry() checks retryable + emittedContent (PR #10)
        → reconnect or fail with clear error

Without this change, errors are silently swallowed and the retry engine in PR #10 never gets a chance to handle them.

Test Results

88 pass
0 fail
189 expect() calls
Ran 88 tests across 6 files.