perf(sse): explicitly disable response compression

[mwbimh]

SSE endpoints now send Content-Encoding: identity alongside existing no-cache/no-transform and buffering headers. This prevents intermediary/server compression from buffering heartbeats and streaming events, improving high-RTT LAN/Tailnet responsiveness and bounding latency. Applies to agent, terminal, file-watch, and provider-login event streams.

Validation: git diff --check passed. Full npm test/build could not run in the workspace because dependency tarballs repeatedly failed integrity checks during npm ci; no dependencies were available initially.

[agegr]

Thanks for looking into SSE latency. I tested this against next start builds of main and of this branch, sending Accept-Encoding: gzip to the agent events, terminal events, file watch and OAuth login streams.

None of them is compressed on main, the login stream included. Next does gzip static assets, but it copies a route handler's headers onto the Node response as arrays, so its compression middleware never sees a string Content-Type and skips the response. With DEBUG=compression it logs [ 'text/event-stream' ] not compressible / no compression: filtered for every stream. That is also why lib/json-response.ts gzips large JSON itself. Next also flushes after every chunk, so nothing is held back.

With this branch the bytes on the wire are identical apart from the extra header, and timings stay within noise: the file-watch change event arrived 8 ms after the write on main and 12 ms here, and a terminal echo took 8 ms and 5 ms. Also, identity is an Accept-Encoding token; the content-coding registry lists it as reserved, so it isn't meant to be sent in Content-Encoding.

So I'm closing this one. Per CONTRIBUTING.md, perf changes need before-and-after measurements. If you see delayed events through a specific setup (a reverse proxy, Tailscale serve, ...), please open an issue with that setup and a timing, and we'll look for the cause there.