Overview

This PR fixes TCP reconnect behavior for radios that briefly accept a PhoneAPI TCP connection, send initial/config data, and then close the socket before the session is actually stable. Previously, any received data reset reconnect backoff to the 1-second floor, so repeated short sessions could hammer a sleeping or recovering radio at roughly 1 Hz. The fix only resets reconnect backoff after a data-bearing session has remained connected long enough to be treated as stable.

Key Changes

Fixes

• Preserved growing TCP reconnect backoff after short data-bearing sessions.
• Added a minimum stable-session threshold before resetting reconnect delay.
• Prevented config-dump-then-EOF sessions from repeatedly resetting backoff to 1 second.
• Kept fast recovery for genuinely stable sessions by still resetting backoff after data is exchanged and the session uptime meets the threshold.
• Left no-data failures on the existing exponential backoff path.

Refactors

• Added SHORT_SESSION_THRESHOLD_MS to document the stable-session cutoff.
• Extracted the reconnect reset decision into shouldResetBackoff(...).
• Moved reconnect reset logic from “any data received” to “data received and session uptime meets the stability threshold.”
• Expanded reconnect logging to distinguish stable sessions that reset backoff from short sessions that keep the current backoff.

Testing

• Added JVM unit coverage for the reconnect backoff reset policy via ShouldResetBackoffTest.
• Covered the reset decision without socket/integration setup:
  • no data => no reset
  • data + uptime below threshold => no reset
  • data + uptime at threshold => reset
  • data + uptime above threshold => reset
• No socket/integration tests are included; the branch keeps transport-loop behavior unchanged apart from the tested reset decision.

Breaking changes / migration

No breaking API or user-facing migration steps are required. Changes are internal to TCP transport reconnect behavior.