v1.1.8

Fix TpapTransport still absorbing a caller's cancellation/timeout: ShouldRetryLiveSession unconditionally treated TaskCanceledException (and an HttpRequestException message containing "A task was canceled") as retryable, and the previous 1.1.5 fix only guarded against the caller's outer CancellationToken already being canceled. SendOnceAsync races each request against its own internal per-request timeout, separate from the caller's outer token; when that internal timeout fired first, the outer token was not yet canceled, so the retry path still triggered a full session Reset() and a brand-new PAKE handshake (whose PBKDF2/EC math performs no cancellation checks at all), potentially running far longer than the caller's configured deadline before an OperationCanceledException finally surfaced. TaskCanceledException/OperationCanceledException (and the related HttpRequestException message) are no longer treated as retryable by ShouldRetryLiveSession; only genuine connection-reset/abort signals and explicit TPAP protocol session-error codes trigger a session reset and retry, so a timeout or cancellation now propagates immediately.

Full Changelog: v1.1.7...v1.1.8