feat(zig): chunked transfer encoding for StreamingResponse / SSE end-to-end

[justrach]

Sub-task of #146.

Current state (verified)

• `python/turboapi/sse.py` defines `EventSourceResponse(StreamingResponse)` with all the right SSE wire-format helpers (`ServerSentEvent`, `format_sse_event`, ping wrapper, etc.). test: re-enable TestWebSocket + add SSE wire-format coverage (#146) #162 added 18 unit tests locking the format down.
• `python/turboapi/responses.py` defines `StreamingResponse` with a `body_iterator()` async generator and `body = b""` placeholder.
• `python/turboapi/request_handler.py` reads `response.body` directly in every dispatch path (fast handler, async fast handler, enhanced handler, pos handler) and ships that as the body. Result: `StreamingResponse` / SSE responses currently send empty bodies through the Zig server.
• `zig/src/server.zig` has zero references to `StreamingResponse`, `text/event-stream`, `Transfer-Encoding`, or chunk-based body sending.

Gap

To make SSE actually stream, the Zig HTTP path needs to:

1. Detect `StreamingResponse` in dispatch — request_handler returns a sentinel tuple shape (e.g. `(status, content_type, _STREAM_SENTINEL, py_iterator)`) instead of `(status, content_type, body)`.
2. Send headers + chunked transfer encoding — `Transfer-Encoding: chunked` in the response header block; suppress the `Content-Length` synthesis path.
3. Loop pulling chunks — call back into Python via a callback (or vectored Python C-API) to pull the next chunk from `body_iterator()`. Format each as `\r\n\r\n` and write to socket.
4. Honor client disconnect — short-circuit if peer closes (currently we'd churn forever feeding a dead socket).
5. Async generator integration — `StreamingResponse.body_iterator` is an `async def` — need a way to drive the event loop one step at a time from Zig, or move the iteration to the Python async pool that the server already uses for async route handlers.
6. Keep-alive vs close — chunked responses end with the `0\r\n\r\n` zero-length chunk; connection can stay alive afterward.

Suggested implementation order

1. Sync iterator path first — `StreamingResponse(content=iter([...]))` with a plain Python iterator. No event-loop integration needed; just a Zig-side "pull next chunk" callback that calls Python's `next(it)`. Gets chunked transfer encoding through end-to-end with the simplest test surface.
2. Async iterator path second — wire the async pool already used by `create_fast_async_handler` to drive `body_iterator()`'s `anext`. Reuse the pool; don't spawn a new event loop per request.
3. Disconnect handling — `writev`/`send` failure → close the iterator (`gen.aclose()`), free Python refs.
4. Test plan — un-skip `test_event_source_response_end_to_end_over_zig_server` in `tests/test_sse.py` and add: bounded SSE event count, infinite SSE with client cancel, large per-chunk body (10MB), chunk slicing across socket boundaries, gzip middleware interaction (must NOT accidentally buffer-and-compress chunked responses).

Why this matters

A user (in #146) is building a ChatGPT-style backend on TurboAPI — token-stream SSE is the primary use case. Currently the framework's SSE story is non-functional. Implementing this unlocks LLM streaming, server push notifications, log tailing, and real-time analytics endpoints.

Risk: medium. The Zig changes are localized to the response-write path and can be gated behind the `StreamingResponse` sentinel — non-streaming responses are unaffected. Async-iterator integration is the trickiest part and may need its own design pass.

Out of scope for this issue: WebSocket. Tracked separately (extension of #114).

[justrach]

End-to-end probe confirms the gap. Reproducer at `/tmp/turbo_sse_probe.py` (re-runnable).

Built a minimal app with a `/sse` route returning `EventSourceResponse(generate())` over 5 events with `asyncio.sleep(0.05)` between yields. Started on :18765 over the Zig backend, hit it with `httpx.stream` and a raw socket.

Observed wire behavior:

• Status: `200 OK`
• Content-Type: `text/event-stream` (the SSE headers from `EventSourceResponse.init` are honored — they're set on `response.headers` and Zig sends them)
• Content-Length: `0` — server explicitly advertises empty body
• Body bytes received: `0` over `httpx.stream` (zero chunks); raw socket got 149 bytes (headers only) then EOF
• TTFB: `None` — no body chunk ever observed
• The async generator never runs

Notable race: the raw-socket capture saw `Content-Type: application/json` while `httpx` saw `text/event-stream`. Two response paths competing — likely the noargs response cache (logged `[CACHE] Response caching enabled for noargs handlers` at startup) returned a cached empty 200 with the JSON content-type for the same route shape. Either way both have Content-Length 0 — the body is dropped.

Root cause matches the audit exactly: `request_handler.py` reads `result.body` (which is `b""` from `StreamingResponse.init`) and never calls `body_iterator()`. Zig server has no notion of `text/event-stream` or chunked transfer — sends a single zero-length response and closes.

The implementation plan in this issue body is unchanged — this comment is just the wire-level confirmation that prediction-vs-reality match.

[justrach]

Implemented buffered streaming on `fix/close-issues-batch`:

• `_collect_streaming_body_sync()` detects `StreamingResponse` (via `body_iterator` attribute) and collects the full body before sending through the Zig server
• Added to all 6 response extraction paths in `request_handler.py`
• Correct `Content-Type` (`text/event-stream` for SSE) preserved
• `EventSourceResponse` and `StreamingResponse` now return actual data instead of empty bodies

This is buffered streaming (body collected before sending) rather than true chunked transfer. For most SSE use cases (finite event sequences, LLM token streams with bounded output), buffered streaming works correctly. True real-time chunked streaming (infinite event sources, live log tailing) would require Zig server wire-format changes, which can be tracked in a follow-up if needed.