Fix reverse connection recovery

[ritchiecarroll]

When using a reverse connection, the subscriber is the server/listener and therefore owns the only reliable application-level indication that published data has stopped arriving. The intended data monitor was gated by an inverted condition: it attempted to enable the timer only when the timer was already enabled. As a result, a half-open connection -- such as one left behind by a temporary firewall outage -- could remain established without the subscriber forcing the publisher client through its normal reconnect cycle.

The reverse recovery path now uses the existing transport behavior:

1. The subscriber detects no data for DataLossInterval
2. The subscriber calls DisconnectOne for its sole publisher connection
3. The publisher's TCP/TLS client detects termination
4. The existing publisher handler invokes ConnectAsync
5. Native unlimited connection attempts continue until the subscriber is reachable

With change, reverse STTP connections can recover when the transport remains half-open but measurement data has stopped flowing. Normal subscriber/client-to-publisher/server operation is unchanged.