Fix Tokio stream cancellation, backpressure and worker lifecycle

[egorsmkv]

Previously each batch created a multi-thread runtime, result delivery could wait for Python on the Tokio thread, abandoned streams continued checking proxies and accumulating results, and a worker panic could leave the iterator waiting forever.

Use a current-thread runtime with I/O and timers enabled, and perform Python result delivery through spawn_blocking. Semaphore credits bound queued item messages by batch concurrency; a slow consumer pauses further scheduling. A watch channel cancels the worker when the stream is dropped or a pending anext is cancelled. Catch worker panics and report thread startup failures. Python function signatures, result dictionaries, request timeouts and proxy behavior remain unchanged.

Behavioral change: cancelling a pending iteration cancels the whole batch. Runtime shutdown waits for an already-running blocking Python delivery; it cannot interrupt arbitrary Python code. Queued results are count-bounded, not byte-bounded, and return_response=True still collects each body in full. At most concurrency queued item messages plus a pending outcome and bounded in-flight checks can retain results. README and changelog document these semantics.

Regression tests cover active-request disconnection on cancellation, slow-consumer backpressure/resumption and stream drop, cancellation wakeups and backpressure waits, completion/drop guards, and panic-to-error conversion. Existing tests cover HTTP status/body behavior and bounded concurrency.

Validation: cargo check --locked --all-targets; cargo fmt; pedantic Clippy with -D warnings; rustdoc with -D warnings; 15 Rust tests and 11 Python tests passed against a built wheel; combined production Rust line coverage 97.77% (395/404), >=90% gate passed; git diff --check. Cargo.lock only reorders the renamed root package canonically.