fix(buzz-agent): classify read timeouts distinctly in LLM error messages

[wpfleger96]

Problem

When buzz-agent exhausts retries on a stalled LLM call, the error message reads:

transport: error sending request for url (...) (cumulative 721s, 3 attempts)

That text is reqwest's generic pre-response failure string — identical whether the cause is a TLS abort, a reset connection, or a read_timeout fire. An operator reading the log cannot tell whether something broke or whether the LLM generation legitimately took longer than the configured timeout.

Root cause (probe-confirmed)

A live probe against goose-claude-fable-5 with a 900s client timeout completed in 370s — well past the default BUZZ_AGENT_LLM_TIMEOUT_SECS=240. Extended-thinking models emit zero bytes on non-streaming calls until generation is complete, so reqwest's read_timeout fires on byte-silence regardless of whether the server is healthy. The 46× exact-721s stall signatures in production logs (3 × 240s + backoff) are deterministic self-inflicted timeouts, not network faults.

Fix

Pure classifier over {is_connect, llm_timeout, phase}

A new timeout_message(is_connect: bool, llm_timeout: Duration, phase: TimeoutPhase) pure function produces factual messages with the configured duration value embedded verbatim. Two thin wrappers (classify_transport_error, classify_body_read_error) extract the reqwest flags and delegate. The duration reaches the classifiers through a new read_timeout: Duration parameter on post() and openrouter_post(); callers pass cfg.llm_timeout.

Messages emitted

Case	Message
Connect-phase timeout (is_connect && is_timeout)	connect timeout: no connection established within 10s
Transport read-timeout	read timeout: no response bytes received within 240s (consider raising BUZZ_AGENT_LLM_TIMEOUT_SECS)
Body-read timeout	read timeout: no further response bytes received within 240s (consider raising BUZZ_AGENT_LLM_TIMEOUT_SECS)
Non-timeout	transport: {reqwest text} / body read: {reqwest text} (unchanged)

LLM_CONNECT_TIMEOUT is now a named const (was inline from_secs(10)).

Out of scope by explicit decision: streaming support, changes to MAX_RETRIES or backoff.

Files changed

• crates/buzz-agent/src/llm.rs — timeout_message pure fn + TimeoutPhase enum + LLM_CONNECT_TIMEOUT const; two classifier wrappers updated; post() and openrouter_post() gain read_timeout param; tests replaced.

Tests

cargo test -p buzz-agent: 397 passed, 0 failed at 294ce5897.

Pure-function tests (no network):

• timeout_message_connect_true_shows_connect_timeout — is_connect=true → connect-flavored text with 10s value; both phases checked
• timeout_message_transport_phase_shows_read_timeout_and_duration — transport phase includes 240s and config knob
• timeout_message_body_read_phase_says_no_further_bytes_and_duration — body phase says "no further", shows 300s
• timeout_message_duration_is_not_hardcoded — 600s supplied → 600s in output, not 240s

Loopback reqwest integration tests:

• classify_transport_error_read_timeout_is_loopback_verified — TCP connect succeeds, server sends no bytes; verifies reqwest sets is_timeout && !is_connect and message contains 50ms value
• classify_transport_error_non_timeout_preserves_reqwest_text — controlled accept-then-close on an owned loopback listener → non-timeout error; asserts exact transport: {err} output equality
• classify_body_read_error_timeout_says_no_further_bytes — loopback server sends headers + 4 bytes of a declared-1024-byte body, then holds; verifies is_timeout, "no further", 100ms value, config knob

No test performs egress beyond loopback (127.0.0.1). The TEST-NET-3 dial is deleted.