fix(sandbox): handle abort signal and early stream close in runCommand

[pbzona]

Summary

When runCommand is called with wait: true, the API returns an ndjson stream with two JSON chunks (command started, command finished). Two problems with how this stream is consumed:

1. Abort signal hangs forever. If an AbortSignal fires mid-stream (e.g. AbortSignal.timeout()), the HTTP body closes but the jsonlines transform stream stays open. The iterator.next() call waiting for the second chunk blocks indefinitely — it never resolves or rejects.

2. Early stream close throws ZodError. If the stream closes after the first chunk but before the second (e.g. server drops connection), iterator.next() returns { done: true, value: undefined }. CommandFinishedResponse.parse(undefined) then throws a Zod validation error instead of a meaningful message.

Fix

• Wire the abort signal to jsonlinesStream.destroy() so pending iterator.next() calls reject immediately instead of hanging
• Check iterator.done before parsing to throw a StreamError instead of a ZodError
• Clean up the abort listener when the stream is fully consumed

Test plan

• throws abort error (not Zod error) when signal aborts before stream finishes — abort mid-stream rejects instead of hanging
• throws StreamError when stream closes before finished chunk arrives — early close throws StreamError, not ZodError
• rejects when signal is already aborted before stream starts — pre-aborted signal rejects immediately
• Existing runCommand and full suite tests still pass

First commit shows the intentionally failing tests to illustrate the behavior. Open to suggestions on the specific error handling behavior, I just don't think it should be a Zod error in these cases. It's technically expected but could be more helpful.

[vercel]

@pbzona is attempting to deploy a commit to the Vercel Team on Vercel.

A member of the Team first needs to authorize it.