fix: Close streaming connections deterministically where the platform allows

[jsonbailey]

What

Fixes a streaming socket leak on both connection-teardown paths — explicit close()/interrupt() and automatic fault-driven reconnect. Previously the socket was released to the pool (release_conn) or the connection reference was simply dropped, so the socket lingered until GC rather than being closed.

The core difficulty: deterministically closing the socket requires first waking a reader that may be blocked mid-recv(), and the mechanism for that is platform- and version-specific:

• POSIX + urllib3 ≥ 2.3 (which added HTTPResponse.shutdown()): resp.shutdown() (SHUT_RD) wakes the blocked reader, then resp.close() tears the socket down deterministically.
• Windows, or urllib3 < 2.3 (no shutdown()): there is no public, non-deadlocking way to wake a blocked reader (shutdown() doesn't interrupt recv() on Windows; closing the socket doesn't reliably either, and going through resp.close() → _fp.close() deadlocks on the reader's BufferedReader lock). So we fall back to release_conn() — the socket leaks until GC (the pre-existing baseline), but it never hangs.

So the per-connection closer is one predicate — "can we safely wake a blocked reader?":

if sys.platform != "win32" and hasattr(resp, "shutdown"):
    if resp.connection is not None:
        try: resp.shutdown()
        except Exception: ...
    resp.close()            # POSIX + urllib3>=2.3: deterministic close
else:
    resp.release_conn()     # Windows / old urllib3: leak, never hang

Also in this PR:

• The reconnect path (sse_client.py _close_current_connection) now routes through the closer instead of dropping the connection reference (the common-case leak).
• _HttpClientImpl.close() closes pooled connections before clear() (on urllib3 2.x, PoolManager.clear() alone does not FIN pooled sockets), for pools eventsource created.
• A floor CI job (UV_RESOLUTION=lowest-direct, Linux + Windows, one Python) guards the minimum declared dependency versions — the regular jobs only run against the locked/latest versions, which is why the urllib3-1.26/2.0–2.2 deadlock corner would otherwise ship untested.

Why

Fixes the FDv1 streaming socket leak (SDK-2668). Net effect vs. the baseline leak: POSIX (urllib3 ≥ 2.3) is now deterministic on interrupt/reconnect/close; Windows and older urllib3 are equal to the baseline (leak, never hang). No breaking dependency change.

urllib3 support

Keeps urllib3 >= 1.26 (no floor bump). urllib3 without HTTPResponse.shutdown() (1.26, 2.0–2.2) transparently takes the release_conn fallback — the same path Windows takes — so those versions leak-but-never-hang rather than deadlocking.

Upstream

The Windows/old-urllib3 leak is only fully fixable upstream: HTTPResponse.shutdown() (added in urllib3#3527 for urllib3#2868) is POSIX-only. A follow-up urllib3 issue tracks making it platform-correct; when that lands, the fallback can be dropped and Windows becomes deterministic too.

Validation

• Full Linux + Windows CI matrix green, plus both floor (lowest-direct) jobs — including urllib3 1.26 on Windows (both fallback conditions at once).
• Local cross-version: urllib3 1.26.20 / 2.2.3 (the last version that deadlocked before this gate) / 2.3.0 / 2.7.0 all pass.
• Concurrent-stop tests assert no hang on all platforms/versions, and reader-wakeup only where shutdown() is available (_CAN_WAKE_READER).