v1.1.6

Fixes LegacyTransport (used by KL130 and other legacy XOR/TCP-protocol devices) not honoring a connect timeout/cancellation promptly.

LegacyTransport.ConnectAsync raced TcpClient.ConnectAsync(host, port) against Task.Delay(timeout, cancellationToken) via Task.WhenAny. On .NET Framework, TcpClient.ConnectAsync(string, int) performs synchronous DNS resolution (Dns.GetHostAddresses) on the calling thread before the returned Task even exists and before the WhenAny race is set up. If DNS resolution was slow or hanging, the connect attempt would block the calling method directly, bypassing the timeout/cancellation race entirely -- so a configured StartupConnectTimeout or an external CancellationToken would not be honored until the underlying synchronous DNS call itself eventually returned.

The connect call is now dispatched to a background thread on .NET Framework 4.7.2 so the synchronous DNS phase cannot delay the timeout race, and .NET 10+ uses the cancellation-aware TcpClient.ConnectAsync(host, port, cancellationToken) overload directly. This complements the v1.1.4 (KlapTransport) and v1.1.5 (TpapTransport) fixes, completing cancellation/timeout coverage across all three transports (KLAP, TPAP, and Legacy).

Full Changelog: v1.1.5...v1.1.6