fix(python): raise on mid-stream body errors instead of silent EOF

[barjin]

Mid-stream body errors (connection reset, truncated chunked transfer) were mapped to StopIteration/StopAsyncIteration, which signal normal end-of-iteration — so for/async for ended silently and callers processed partial bodies as complete (a silent data-integrity bug, #475). Both sync and async iterators now propagate the classified ImpitError as a real exception and set the consumed/closed flags consistently with the clean-EOF branch.

Streamed truncation surfaces in reqwest as a Decode-kinded error rather than Body, so the existing unexpected-EOF classification missed it and fell through to the catch-all HTTPError. The guard is widened to cover is_decode(), so truncated streams now raise RemoteProtocolError, matching httpx.

Verified against a vanilla server that truncates the body mid-response; added sync + async regression tests.

Closes #475

[Pijukatel]

Could this potentially cause something similar to this in Python?

Worth double-checking that we will not get some new client problems due to weird API behavior that was previously silently ignored

[barjin]

Thank you @Pijukatel , that's a good point there.

According to my tests, the behaviour actually differs between ActorClient and AsyncActorClient in apify-client-python.

While ActorClient (synchronous) spawns a thread, AsyncActorClient spawns an asyncio Task .

From what I noticed, the async Task will rethrow the new Impit error (causing the whole process to fail), while the Thread will only log the error, but return correctly on t.join() and allow the process to continue as expected.

I'd leave the final decision on the client maintainers, but imo both the Async and sync clients should handle exceptions the same (i.e., ignore in this case?). Wdyt?