fix(http): unblock request reader after Zig 0.16 migration

[Kures]

PR5 — fix(http): unblock request reader after Zig 0.16 migration

Branch: fix/http-read-blocking
Fixes: every HTTP endpoint times out on main since 54455f9 (PR #5, Zig 0.16 merge, 2026-04-17). The published 2026.3.2 image is unaffected because it predates that merge.

Why

After the Zig 0.16 migration landed, anyone building from main HEAD
finds that curl http://localhost:8080/health hangs until its timeout.
TCP handshakes succeed, the request is read, the handler runs, but the
response only reaches the wire 3-5 seconds after the request — by
which time the client has already given up.

The unit-test suite (zig build test) stayed green at 340/340 because
tests exercise api.handleRequest directly and never go through the
live accept-read-write loop in src/main.zig.

Root cause

Not the writer chain. The reader.

readHttpRequest calls reader.interface.readSliceShort(&chunk) with
chunk: [4096]u8. Per the Zig 0.16 documentation:

Returns the number of bytes read, which is less than buffer.len if
and only if the stream reached the end.

So readSliceShort blocks until the destination buffer is fully
filled or the stream EOFs. A typical GET /health is ~84 bytes, so
the reader sat waiting for another 4012 bytes that would never come.
The connection only progressed when curl gave up after its timeout
and FIN'd the socket — at which point readSliceShort returned the 84
bytes it had been holding, the handler ran, and the response was sent
into a socket the client had already closed.

tcpdump on the loopback interface confirmed the timeline (request
ACK'd at t=0, response packet leaving the server at t≈5s, RST from
the client immediately after).

Fix

Replace readSliceShort with readVec. readVec performs at most
one recv syscall per call and returns whatever the kernel has —
typically the entire HTTP request in one shot. The surrounding
while loop already handles fragmented requests correctly.

Diff (src/main.zig, in readHttpRequest):

-        const n = try reader.interface.readSliceShort(&chunk);
+        var data: [1][]u8 = .{&chunk};
+        const n = reader.interface.readVec(&data) catch |err| switch (err) {
+            error.EndOfStream => return null,
+            else => |e| return e,
+        };

Four added lines, one deleted. No other code changes.

Verification

Reproducer from the issue draft (build main from source, run with
the unmodified ziglang/zig:0.16.0 toolchain in Docker, hit
localhost:8080 with curl):

Before
  $ curl -m 5 -i http://localhost:8080/health
  curl: (28) Operation timed out after 5001 ms with 0 bytes received

After
  $ curl -m 5 -i http://localhost:8080/health
  HTTP/1.1 200 OK
  Content-Type: application/json
  X-Request-Id: ab01511c-3cc9-4114-bec3-dd5c060b4147
  Content-Length: 70
  Connection: close

  {"status":"ok","version":"2026.3.2","active_runs":0,"total_workers":0}

Per-request timing measured in the accept loop:

Phase	Before	After
accept	0 ms	0 ms
readHttpRequest	5002 ms	1 ms
handler + write	<1 ms	<1 ms

/health and /metrics both respond in roughly 2 ms end-to-end.
zig build test --summary all is still 340/340 passing — the fix
does not regress any covered behaviour.

Closing the test-coverage gap

The reason this regression slipped through was that none of the 340
unit tests exercised the live accept-read-write loop — they all call
api.handleRequest directly. So a second commit on this branch
(e7fc120) adds an in-process integration test that:

• binds 127.0.0.1:0, connects a libc client socket from the same
  thread (kernel's listen backlog handles the lack of a separate
  thread),
• sends a small HTTP request with no FIN (write side stays open),
• calls readHttpRequest on the accepted Stream,
• asserts the call returns in under 200 ms with the request parsed
  correctly.

SO_RCVTIMEO of 2 s on the server-side socket converts a regressed
"hangs forever" into a clean failure rather than a hung CI run.

Verified the test catches the regression by temporarily reverting
readVec to readSliceShort:

Configuration	Result
readSliceShort (regressed)	340 pass, 1 crash (the new test) within ~2 s
readVec (fixed)	341/341 in 1 s

The test is skipped on Windows because it reaches directly into libc
socket primitives. A platform-portable equivalent would need a
Winsock branch, which we do not need for the regression we are
guarding here.

Why I'm filing this as a PR

The original issue draft hypothesised about writer.flush() swallowing
the bytes and listed two failed workarounds. Those guesses were on the
wrong layer — the writer chain is fine, it just never gets a chance
to run because the reader stalls upstream. Once the reader is fixed,
the unmodified writer code from the Zig 0.16 migration delivers the
response correctly.