HTTP hooks: no retry when the OS resets a local connection (read ECONNRESET / ECONNREFUSED), hook output silently dropped

Follow-up to #29963 (closed as inactive, locked; the bot asked to open a new issue referencing it). The problem is still present, and this time the kernel shows who drops the connection.

Environment: Claude Code 2.1.280, Windows 11 (26200), PreToolUse http hooks pointing at a local server (32 declarations per tool call, spread over 4 local ports).

What happens: on ~1.4 % of hook POSTs the hook fails with read ECONNRESET, and on ~0.85 % with connect ECONNREFUSED, in bursts. The hook output for that tool call is lost; the tool call proceeds without it.

What we measured: a Windows kernel trace (Microsoft-Windows-TCPIP ETW provider) shows the reset is issued by the OS itself (pid=0), neither by the server nor by the Claude Code process: event 1046 "terminating: retransmission timeout expired", then "sent RST ... Reason = Connection aborted". Both ends receive the RST within 2 ms. The server's own log shows it was idle and still waiting for the request body. The same event 1046 precedes the ECONNREFUSED cases. At rest the local path is fast (0.15 ms round trip); smoothed RTT during an episode read 656 ms. The Windows firewall (WFP audit) dropped nothing.

Request:

1. One bounded retry on a fresh connection for http hooks on ECONNRESET / ECONNREFUSED before the request was answered. The handler never processed it, so the retry is safe for any hook that is idempotent per tool_use_id.
2. Optionally, a local IPC target for http hooks (Windows named pipe / Unix socket), which takes TCP out of the path entirely.

Happy to share the trace excerpt and a reproduction setup.