fix(http): don't back off from healthy SSE reconnects, and don't log them as errors

[ForrestThump]

Two related defects in sse_connection_task, found and then measured on a self-hosted box that was producing 93,532 SSE log lines in 24h on an idle connection.

1. Backoff never applied to a stream that opened and collapsed

info!("SSE connection established");
attempt = 0; // Reset attempt counter on success

The sleep at the top of the loop is guarded by if attempt > 0. A server that accepts the GET and then closes the stream therefore reconnects with zero delay, and the counter never accrues because the next accept resets it again. Backoff only ever applied to connections that failed to open.

Reproduced against v3.x with a TcpListener that accepts, sends valid SSE headers, and hangs up:

	connections in 2s
before	7,657
after	5

2. Routine reconnects were logged as errors — this was the actual log volume

The first fix alone was not the right remedy, and deploying it proved that. The real server closes idle streams on a 30s timer: measured uptimes were 29.9999s, every time, without variance. So the cycle was never a spin — it was one reconnect per 30s per peer, times ~12 peers, times 3 log lines each.

Two consequences:

• A fixed 30s threshold classified every ordinary cycle as a failure. Backoff accrued against normal operation, heading for max_attempts and abandoning the channel — trading log noise for lost server→client notifications, which is worse than the noise.
• Logging a normal reconnect at error/warn is the defect. A server closing an idle stream is behaving correctly and the client reconnecting is it doing its job.

So: sse_healthy_stream_threshold is configurable, defaulting to 10s — comfortably under the round-number idle timeouts servers actually use. And stream_was_healthy decides both the backoff counter and the log level, so the two cannot disagree. A short collapse still warns; the read error is debug when the stream had lived and error only when it had not.

Measured in production

Same box, same 90-second window, before and after:

	SSE ERROR/WARN lines	total log lines
before	61	141
after	0	57

Zero backoff engaging, zero ERROR lines in 5 minutes, MCP tool surface intact, container healthy. The channel is maintained rather than abandoned — which is the part the first attempt got wrong.

Tests

• a_server_that_closes_the_stream_immediately_does_not_get_hammered — real loop vs a server that hangs up instantly. Restoring the old reset-on-connect: 7,657 connections in 2s.
• a_stream_that_lives_past_the_threshold_is_not_treated_as_a_failure — real loop vs a server that holds the stream then closes. Setting the threshold above the server's close time (the mistake fixed here) takes it from 4 connections in 1.5s to 1.
• Four unit tests over the rule: immediate collapse counts as failure (including just-under-threshold), long-lived resets, the counter saturates rather than wrapping back to 0, and three straight collapses earn a real delay.

No new dependencies — raw TcpListener.

A note, since two earlier versions of the integration test were useless

Both passed with the fix removed. Writing response headers and dropping the socket immediately makes reqwest report a connect error, which takes the Err branch that already backs off correctly — so the success path never ran. Connection: close is also needed, or reqwest pools a socket the server is about to drop. The working version needs all three: handle off the accept loop, hold the socket open for a complete response, and Connection: close.

Behavioural note

A stream that always collapses still exhausts max_attempts and gives up on the standalone channel. That's consistent with the existing design — connect failures already exhaust, and the HTTP 405 path already logs "Continuing without standalone SSE polling" and breaks. With the corrected threshold this now only affects genuinely pathological servers, not ones with an ordinary idle timeout.

Scope

v3.x only. main (V4) has no equivalent client reconnect loop, and its HTTP transport ships DEFAULT_SSE_KEEPALIVE = 15s, which prevents the idle-close that triggers this at all. Raising it here because the branch still takes bug fixes.

turbomcp-http suite green (21 tests); clippy -D warnings and cargo fmt clean.