fix(agent): close proxy ingest upload per batch so events stream live

[charlesvien]

Problem

Cloud task runs stream agent output to the browser through the agent-proxy: the sandbox POSTs events to the proxy ingest endpoint (write leg), the proxy writes them to a Redis stream, and the browser consumes them over SSE (read leg). The read leg works, but live output never showed up on the proxy write leg — the browser sat on keepalives and then received the whole turn in one burst (or on refresh from persisted history).

Root cause is the write leg's transport. The ingest sender streams events into a single long-lived chunked POST that stays open until the stream window rolls. The ingress in front of the proxy buffers the request body and only forwards it once the request closes, so the proxy receives nothing until the upload rolls. Streaming a response (SSE) is well supported; dribbling bytes into a long-lived request body is not — intermediaries buffer it. The tell: the empty bounded sequence-sync probe always arrives immediately, while the long-lived content upload doesn't land until it closes.

Changes

After a flush drains the buffer, close the active upload instead of holding it open, gated to the proxy write leg (usingProxy). Each drained batch now rides its own promptly-closed request, so a buffering ingress forwards it within a round-trip and delivery is effectively live. Sequencing, backpressure, 409 rebase and restart-resume are unchanged — only the moment we close the upload moved.

This supersedes the short-window stopgap from #3042: per-batch close makes a shortened proxy window redundant (the upload closes per batch, so a window never trips), so DEFAULT_PROXY_STREAM_WINDOW_MS is removed and the window default is a single value again.

Scope is limited to the proxy path on purpose:

• Proxy write leg (usingProxy): close per batch → live delivery.
• Django path: untouched — keeps its existing long-lived upload and window.
• Stop path: unchanged — still writes the completion line onto a final upload via drainForStop (that path runs under stopped, where the new close is skipped).

How did you test this?

I'm an agent (Claude Code), human-directed. Automated tests I actually ran, all green:

• vitest run src/server/event-stream-sender.test.ts (17 pass). Replaced the old "keeps the active ingest request open across scheduled flushes" case — that held-open behavior was the bug — with "closes the active ingest upload after each drained batch on the proxy path", which drives the proxy path and asserts each batch is delivered and closed before stop() while the completion line rides a final upload. The Django-path cases (no eventIngestBaseUrl) are unchanged and still pass, confirming the gate.
• tsc --noEmit and biome check on the changed files — clean.

I did not run a full sandbox-to-browser flow in a live environment.

Automatic notifications

• Publish to changelog?
• Alert Sales and Marketing teams?

[greptile-apps]

_{Reviews (1): Last reviewed commit: "close ingest upload after each drained b..." | Re-trigger Greptile}

[github-actions]

React Doctor found no issues in the changed files. 🎉

_{Reviewed by React Doctor for commit 3623e13.}

[github-actions]

Clean, well-reasoned fix that replaces a 1-second timer-based proxy stream close with an immediate per-batch close, correctly guarded from the stop path. No data model, API contract, dependency, or infra changes.

[greptile-apps]

_{Reviews (2): Last reviewed commit: "close ingest upload after each drained b..." | Re-trigger Greptile}