Batch result decoders leave responses open after parsing or transport errors

[betacatsling]

When a batch-result JSONL stream raises a JSON decoding or transport-read error, its HTTP response stays open. The caller catches the error, but the connection is not released unless they also explicitly close the result decoder.

Reproduced on main eb21a4352015686c30f5759e8c2f02d70f5371e2, Python 3.10/Linux, for both sync and async client.messages.batches.results(). A minimal reproducer of the decoder used by that endpoint is:

import json
import httpx2
from anthropic._decoders.jsonl import JSONLDecoder

response = httpx2.Response(200, stream=httpx2.ByteStream(b"invalid json\n" + b" " * 64))
decoder = JSONLDecoder(
    raw_iterator=response.iter_bytes(chunk_size=64),
    line_type=object,
    http_response=response,
)
try:
    list(decoder)
except json.JSONDecodeError:
    pass
print(response.is_closed)  # False; expected True after the iterator fails
response.close()

The same leak happens if the underlying byte stream raises httpx2.ReadError. Successful exhaustion already closes the response through HTTPX. The error paths should release it as well, matching the SDK's SSE stream cleanup.

AI assistance was used for investigation and local verification; no API calls were made to a live provider.