lean_api, upstreams, poller, server: bound poll workers with SO_RCVTIMEO / SO_SNDTIMEO

[ch4r10t33r]

Fixes #13.

Summary

• Apply SO_RCVTIMEO / SO_SNDTIMEO on the HTTP request's underlying TCP socket after client.open() so blocking recv/send returns within request_timeout_ms instead of hanging on the kernel's TCP retransmit window (~15 min on Linux).
• Thread request_timeout_ms through fetchSlots, fetchSlotFromSSZEndpoint, fetchJustifiedSlotFromJsonEndpoint and fetchForkChoice; update callers in poller.zig, upstreams.zig (via PollCtx) and server.zig.

Why

Zig 0.14's std.http.Client does not expose connect/read timeouts — the @hasField guards in poller.zig / server.zig are no-ops on 0.14.1. To enforce a deadline, pollUpstreams spawns a worker per upstream and abandons stragglers via thread.detach() after request_timeout_ms. But detaching does not cancel the thread: if the peer accepted the TCP connection and then stopped responding (or half-closed with FIN), the worker stays blocked inside recv() with the socket still open. The process accumulates ESTABLISHED / CLOSE-WAIT sockets until RLIMIT_NOFILE is exhausted and the service becomes unreachable for both outbound and inbound connections.

Socket-level receive/send timeouts unblock the detached worker deterministically; its existing defer client.deinit() then closes the socket within the deadline.

Scope

Only addresses post-connect() hangs, which matched the observed incident (full detail in #13: 1021 socket fds with 960 ESTAB + 63 CLOSE-WAIT). Connect-phase black-holes (SYN with no SYN-ACK) still rely on the kernel's retransmit window; switching to non-blocking connect is left as a follow-up.

Test plan

• zig fmt --check src
• zig build
• zig build test
• Deploy to the tooling server and confirm ls /proc/$PID/fd | wc -l stays flat across upstream outages (previously grew monotonically).