v1.1.5

Fixes TpapTransport swallowing the caller's own cancellation request.

TpapTransport.SendAsync (and the periodic keepalive path) caught TaskCanceledException as a generically 'retryable' live-session condition via ShouldRetryLiveSession, and unconditionally reset the session and retried the request -- including a full handshake -- whenever that exception type was seen. This happened even when the TaskCanceledException was actually caused by the caller's own external CancellationToken being canceled, rather than the transport's internal per-request timeout. As a result, an external cancellation request (e.g. a driver requesting a 20 second cancellation) could be silently absorbed by a retry attempt instead of propagating immediately, so the caller would still observe the full duration of a brand-new handshake+request cycle rather than a prompt cancellation.

Both SendAsync and SendKeepAliveCoreAsync now check cancellationToken.IsCancellationRequested before retrying: a genuine external cancellation now propagates immediately as OperationCanceledException instead of triggering a session reset and retry. This is a more impactful fix than the v1.1.4 KlapTransport change for scenarios that use the TPAP transport (Tapo devices).

Full Changelog: v1.1.4...v1.1.5