fix: stop the standalone GET stream reconnecting forever on empty connections

[heyhayes]

Summary

Split out from #2122. Since that PR was opened, its core fix — propagating an error to a waiting request when an SSE stream ends without a response — has landed upstream independently via the _resolve_abandoned_request helper (introduced in #3047), which resolves an abandoned request with a synthesized error both when an id-bearing stream ends unresumably and when reconnection attempts are exhausted.

This PR carries forward only the two fixes from #2122 that are not covered by that work. Relates to #1401.

What changed

Stop the standalone GET stream reconnecting forever on empty connections. handle_get_stream reset its attempt counter to 0 whenever a connection ended "normally" — i.e. the async for over the SSE events completed without raising. A server that accepts the GET but immediately closes the stream with no events hits exactly this path, so the counter never advances and the client reconnects in an unbounded loop (throttled only by the reconnect delay). The counter now resets only when events were actually received; empty connections count toward MAX_RECONNECTION_ATTEMPTS, so the loop gives up. That give-up branch was previously marked unreachable (# pragma: no cover) — it is now reachable and covered by a test.

Log unhandled exceptions in the default message handler. Transport-level errors not tied to a specific pending request (e.g. a GET stream failure) reach _default_message_handler as an Exception item and were silently discarded. It now logs a warning as an observability safety net.

Testing

• New regression test drives repeated empty GET streams and asserts the loop terminates after MAX_RECONNECTION_ATTEMPTS rather than reconnecting forever.
• New test asserts _default_message_handler logs a warning for an Exception item.
• Full suite green; both changed files at 100% branch coverage.