reliability: device layer never notifies IsConnected transitions (stale command/UI state on silent drops) #3

Summary

AbstractStreamingDevice.IsConnected is a computed property (=> CoreDevice?.IsConnected == true) that is never raised via OnPropertyChanged anywhere, and Core's transport StatusChanged is not bridged to it. So a silent transport drop (notably a WiFi/TCP link dying without an explicit Disconnect() or a USB-removal WMI event) raises no notification — any VM binding or command gated on IsConnected can read stale until the next unrelated signal.

Where it bites

Surfaced by PR #2 (SD offload over WiFi, closes #1): DeviceLogsViewModel.CanAccessSdCard now depends on SelectedDevice.IsConnected, so a dropped device can leave the SD refresh command / empty-state UI looking enabled until the next reachable signal. PR #2 mitigates the reachable paths (re-raises the SD gate on ConnectionManager "ConnectedDevices" changes — explicit disconnect + USB removal) and guards every SD operation with an IsConnected re-check at call time (so no op runs against a dead transport), but the fully-silent WiFi-drop case has no event to hang reactivity on.

This is app-wide, not SD-specific: any IsConnected-derived binding has the same latency.

Proposed fix (device layer)

• Bridge Core's transport StatusChanged (disconnect) to OnPropertyChanged(nameof(IsConnected)) on AbstractStreamingDevice, and raise it on connect/cleanup too.
• Optionally surface a ConnectionLost event so ConnectionManager can drop a silently-dead WiFi device from ConnectedDevices (today only USB removal is watched, via Windows-only WMI — no mobile/WiFi equivalent).
• Once IsConnected notifies, VMs can bind/subscribe directly and drop the connected-set-change workaround.

Acceptance

• A WiFi device whose TCP link drops (no explicit disconnect) flips IsConnected → false and raises the change; dependent commands/UI update without a selection change.
• Works cross-platform (not gated on Windows WMI).

Filed from PR #2 review (Qodo "SD access state stale").