Fix(http): Release the underlying connection when an AbortableRequest is aborted before its body is read

[hasanmhallak]

After send returns, IOClient owns the dart:io HttpClientResponse but subscribed to it lazily — only when the wrapper stream was listened to. Aborting in the window between "response received" and "body listened" closed the wrapper without ever touching the native response, so dart:io kept the connection open waiting for a body no one would read. With a bounded pool, the next request hung until timeout.

Abort after pipe is now handled by a single abortResponse that covers all three states:

• Never listened to — cancel the native response to release the connection.
• Streaming — emit RequestAbortedException and cancel the live subscription.
• Already fully read — no-op.

The wrapper still emits RequestAbortedException and closes. The body is destroyed, not drained.

Tests

• aborting without reading the response frees the underlying connection
• aborting after the response is fully read raises no async error
• aborting while streaming frees the connection

Fixes #1934

---

• I’ve reviewed the contributor guide and applied the relevant portions to this PR.

Contribution guidelines:

• See our contributor guide for general expectations for PRs.
• Larger or significant changes should be discussed in an issue before creating a PR.
• Contributions to our repos should follow the Dart style guide and use dart format.
• Most changes should add an entry to the changelog and may need to rev the pubspec package version.
• Changes to packages require corresponding tests.

Many Dart repos have a weekly cadence for reviewing PRs - please allow for some latency before initial review feedback.

Note: The Dart team is trialing Gemini Code Assist. Don't take its comments as final Dart team feedback. Use the suggestions if they're helpful; otherwise, wait for a human reviewer.