client: stop the client-stream transport task when the call is abandoned

[EffortlessSteven]

What this does

Abandoning a call_client_stream call (dropping its future or hitting the deadline) while the transport is still awaiting response headers leaves the background transport.send(...) running indefinitely: the detached task driving it only checks the receiver after the send resolves.

Fix: the spawned task now stops the send when the caller stops waiting (future dropped or deadline fired). The response and transport-error paths are unchanged.

Note that this is also a behavior change, not only a leak fix: abandonment now cancels the underlying request, so a request that was still being sent may never reach the server. The # Cancellation docs and the changelog entry call this out, matching the equivalent BidiStream documentation from #221.

Verification

Unpatched, the abandonment tests time out: the transport send future is never dropped.

Check	Result
abandon: deadline / cancel / mid-drain	unpatched: send never dropped; patched: dropped
success, transport-error paths	unchanged
fmt, clippy -D warnings, test	clean / 562 passed

Review map

• call_client_stream: the spawned send task selects transport.send(...) against resp_tx.closed(), so a dropped receiver (cancellation or deadline) stops the send instead of leaving it detached.
• connectrpc/Cargo.toml: the always-compiled call_client_stream now uses tokio::select!, so the base tokio dep gains macros; the server feature's own tokio/macros entry is dropped as redundant, with a note on the base dependency explaining why macros is load-bearing.
• tests: pin both abandonment paths dropping the send future (with mid-drain backpressure), and preserve the success and transport-error paths.
• maintainer fixup (6f67559): documents the delivery caveat in the rustdoc and changelog, adds a # Cancellation note to call_server_stream, and consolidates the tokio/macros feature declaration.

Fixes #224

[iainmcgin]

[claude code] Reviewed on Iain's behalf; approving.

Verification performed locally:

• Reverted just the fix (keeping the new tests) and confirmed all three abandonment tests fail unpatched and pass patched — they genuinely gate the bug.
• Confirmed the ownership invariant the fix relies on: resp_rx lives inside the timeout_at-wrapped block, so both abandonment paths (future drop, deadline expiry) drop it, and the spawned task's closed() branch then drops the in-flight send. The simultaneous-readiness race is benign in both directions.
• Confirmed this was the last detached transport-send spawn in the client (call_bidi_stream keeps its JoinHandle per #221; call_server_stream awaits the send inline), closing out the #224 leak class.

I pushed a small maintainer fixup (6f67559) rather than round-tripping review comments: it documents the caller-visible consequence (an abandoned call now cancels the underlying request, so a request still being sent may never reach the server — the same caveat #221 documented for BidiStream), adds the matching # Cancellation note to call_server_stream, consolidates the now-redundant server-feature tokio/macros entry into a note on the base dependency, and rewords a few test comments into code-present tense.

Thanks for the contribution — the started_rx gate proving the drop is of an in-flight (not merely unpolled) future is a nice touch, and the mid-drain backpressure case is exactly the coverage this needed.