Honor LocalInterfaceAddress when connecting discovered WiFi devices

[tylerkron]

Problem

WiFiDeviceFinder populates IDeviceInfo.LocalInterfaceAddress, but the TCP connection path does not use it. DaqifiDeviceFactory.ConnectFromDeviceInfo(...) forwards only the remote IP/port, and TcpStreamTransport has no way to bind the outbound socket to the discovered local interface.

Impact

In multi-NIC environments, UDP discovery can succeed on one interface and the follow-up TCP connection can still egress on a different interface. That makes a discovered device effectively unconnectable even though discovery metadata already contains the correct local interface.

Suggested Fix

• Extend the TCP transport/factory path to optionally bind the client socket to a local interface before connecting.
• When ConnectFromDeviceInfo(...) is called for a WiFi IDeviceInfo, honor LocalInterfaceAddress if it is present.
• Keep existing behavior unchanged when no local interface is supplied.

Acceptance Criteria

• A discovered WiFi device with LocalInterfaceAddress set uses that interface for the outbound TCP connection.
• Existing callers that connect by host/IP without a local bind keep their current behavior.
• Add a focused test covering the ConnectFromDeviceInfo(...) WiFi path with a supplied local interface.

Context

This came up while removing Desktop-side WiFi metadata wrappers so discovery/connect behavior can rely more directly on daqifi-core. The remaining gap is in Core transport selection, not Desktop discovery metadata.