fix: Keep a failing background watcher from breaking a successful actor call

[vdusek]

Description

actor.call() with the default logger='default' could raise on a run that had already succeeded. A status poll that failed after retries left the exception on the watcher task; stop() then cancelled an already-finished task and awaited it, re-raising past except asyncio.CancelledError. The sync twin leaked the same failure out of its thread.

• Both watcher loops now use the handler StreamedLog._stream_log already had: warn on is_timeout_error, logger.exception otherwise. A failed poll gets reported and the run's own result stands.
• The sync watcher's thread is a daemon, so a watcher whose loop never terminates cannot hold up interpreter shutdown.
• StreamedLog.stop() closes the stream response and caps its join at _stop_timeout_s (5s), where it used to join unbounded on a stream that may not speak for hours.
• start() on both sync classes checks is_alive(), so a handle left by a thread that outlived its stop does not block a restart.

The close alone is not enough. On Impit 0.13.2 Response.close() returns immediately and sets is_closed=True, yet a reader blocked in iter_bytes() stays blocked, and closing the Client does not release it either. The close is kept because it is correct for a custom HTTP client, and the capped join is what makes stop() return.

Why stop() is bounded this way

• fix: prevent StreamedLog stop() from hanging on a silent stream #825 bounded stop() by requesting the log stream with a 30s read timeout.
• fix: prevent Actor log-streaming thread from crashing on stream timeout #944 removed that: Impit applies timeout to the whole request, streamed body included, so a run logging past the bound was cut off mid-stream with impit.TimeoutException (impit.TimeoutException in _streamed_log.py after successful actor completion #945). The stream has used no_timeout since, with the unbounded stop() recorded as a known limitation.
• This PR caps the join and closes the response, leaving the stream request alone. _stream_timeout stays no_timeout, still asserted by test_streamed_log_sync_requests_stream_with_no_timeout, so impit.TimeoutException in _streamed_log.py after successful actor completion #945 cannot regress. What it fixes is the case fix: prevent Actor log-streaming thread from crashing on stream timeout #944 left open: a manual stop() on a stream gone quiet.

Trade-off: a thread outliving the 5s cap keeps running as a daemon, so stop() can return before the tail is flushed. On the actor.call() path the run's EOF ends the thread first, measured at 0.000s over repeated apify/hello-world runs.

Test plan

• 8 unit tests and an integration test that fails a real run's background status polls, each red before the fix.

✍️ Drafted by Claude Code

[codecov]

Codecov Report

❌ Patch coverage is 96.15385% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 95.25%. Comparing base (10ace92) to head (2020ac1).

Files with missing lines	Patch %	Lines
src/apify_client/_status_message_watcher.py	91.30%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1027      +/-   ##
==========================================
+ Coverage   95.24%   95.25%   +0.01%     
==========================================
  Files          59       59              
  Lines        5514     5547      +33     
==========================================
+ Hits         5252     5284      +32     
- Misses        262      263       +1     

Flag	Coverage Δ
integration	92.06% <67.30%> (-0.14%)	⬇️
unit	87.41% <96.15%> (+0.05%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.