Overview

This pull request makes the BLE Kable connection fallback policy explicit inside KableBleConnection.connect(...).

Before this change, the direct-connect → autoConnect fallback behavior was encoded as a while (state != Connected) loop with an internal autoConnect flag flip. The intended behavior was bounded, but a reader had to trace mutable state to verify that each connect(...) call only attempts the direct path and then the autoConnect fallback.

This change makes that invariant structural: each connect(...) call performs at most two inner Kable attempts, while BleRadioTransport remains responsible for the outer reconnect/backoff loop.

Key Changes

• Replaced the implicit while (state != Connected) retry structure with an explicit bounded loop.
• Preserved the existing connection order:
  • direct connect first when a fresh advertisement is available,
  • autoConnect fallback second,
  • advertisement-less devices start on the autoConnect path.
• Added a final state check so connect(...) cannot report success unless Kable reached Connected.
• Kept macro reconnect/backoff ownership in BleRadioTransport.
• Updated KableBleConnection documentation to describe the inner fallback policy.
• Added focused coverage proving repeated bounded inner failures do not stop the outer reconnect policy from reaching a later successful attempt.

Testing

• Added BleReconnectPolicyTest coverage for repeated connection failures followed by recovery.
• Verified the outer reconnect policy continues after repeated failed inner connection attempts.

Migration Notes

• No user data migration is required.
• No BLE address format changes are introduced.
• The outer BLE reconnect/backoff policy remains unchanged.