fix(cli): end a stalled cloud upload and send it again - #7237

Requesting changes at 3161c0f9.

Blocker: the project zip upload still has no stall bound, and it is the upload this PR is about.

cloud render uploads the project with uploadZipViaDirectUpload({ bytes: archive.buffer, … }) (commands/cloud/render.ts:874). A Uint8Array body takes putBytesOnce, a plain fetch with no stall timer. Only putFileToPresignedUrl (the file-on-disk path, used for large media assets) arms putTimings.stallMs. On a dead link the zip PUT still waits for undici or the OS. Because that PUT is now wrapped in putWithRetry, the hang can repeat up to four times instead of once.

I reproduced this on this head with a probe that copies the PR's own withPlan(["hang", 200]) harness and sets stallMs: 150, but uploads bytes instead of path. It never ends the first try and times out after 8 s. The same probe through the path route passes. All three new tests use path, so nothing covers the bytes route.

Fix: put the same no-progress bound on the bytes path. Either send the buffer through the http(s).request path (for example Readable.from([body]) or chunked slices, so the same arm() runs), or give fetch an AbortController that a progress timer resets. Then add the ["hang", 200] case for a bytes upload. The PR title and body should also say which uploads are covered.

Checked and fine:

• The named test, ends a try that moves no data and sends the file again, fails when upload.ts is reverted to the merge base (5 s timeout) and passes on this head. 29/29 pass in upload.test.ts and errors.test.ts on this branch.
• Errors below 500 are final, 5xx and network errors are retried, a fresh read stream is opened per try, and the timer is cleared once the response arrives.

Non-blocking:

• The timer is re-armed on data events from the read stream (disk reads), not on bytes leaving the socket. After the last read (end), only one 60 s window covers draining the writable and kernel send buffers plus S3's reply. On a very slow uplink with a large send buffer, that tail could exceed 60 s. A link that is slow but still moving could then be ended near the end, and each retry would restart from byte 0. Re-arming on socket drain/progress, or allowing a longer window after end, would make "slow but moving links are never ended" hold.
• sleep() between tries ignores signal, so an abort waits out the current backoff (up to 4 s). Errors that aren't network errors (for example ENOENT on the file) are also retried three times.

Approving at 96538241. The blocker from my review at 3161c0f9 is fixed.

Blocker fixed: uploadZipViaDirectUpload from cloud render passes no fetchImpl, so the in-memory zip now goes through putStreamToPresignedUrl in 64 KB slices and gets the same stall watch. The new test bounds the project zip, which is sent from memory, the same way fails on the previous head's upload.ts (5 s timeout) and passes here. The test from the "fails without the fix" line still fails on the merge base. On this head, 30/30 pass in upload.test.ts and errors.test.ts, and tsc shows no errors in cloud/upload.ts.

Other earlier notes:

• The abort now ends the backoff sleep. The next try then throws immediately on the aborted signal.
• ENOENT and EACCES are final.
• Stall detection now watches req.socket.bytesWritten instead of disk reads. Backpressure stops that counter on a dead link, so a stall is still caught.

Non-blocking:

• socket.bytesWritten counts bytes handed to the socket, including its JS and libuv queues, not bytes the peer has acknowledged. After the last slice is written, a single 60 s window still covers draining the kernel send buffer plus S3's reply. The tail risk I raised earlier for very slow uplinks is smaller but not gone. The PR body's "bytes actually sent" overstates it slightly.
• Callers that pass their own fetchImpl keep the fetch path without the stall watch, but now get retries. In-repo, those are audio/analysis/providers/api.ts (boundedFetch) and stems.ts, whose fetch is bounded by its own AbortSignal.timeout. That's fine as it stands.
• sleep() never removes its abort listener when the timer fires (at most 3 per upload).

Approving at 2bcc8d4f. Compared with 96538241, which I approved earlier, this is a refactor with no change in behavior.

• Same base: both heads sit on merge base 216395e9. The only new commit is 2bcc8d4f, which touches only cloud/upload.ts.
• What moved: the retry-final condition moved into isFinal(), the socket bytesWritten interval moved into watchStall(req) (which returns its clear function), and reading the response moved into settle(res, sent). The logic, constants, error messages and order of operations are unchanged. The cleanup in finally still runs before the body is read.
• Tests: none changed. 30/30 pass in upload.test.ts and errors.test.ts on this head, and tsc shows no errors in cloud/upload.ts.

My earlier non-blocking notes still apply: the tail after the last write, fetchImpl callers keeping the fetch path, and the abort listener in sleep().