fix(nrf52): add BLE security timeout and advertising watchdog

[ipduffy]

Commit 25ea953 introduced a condition where a BLE connection that is established but not yet encrypted could result in a hung BLE stack under certain conditions.

If onConnect is called with a valid connection_handle, the _isDeviceConnected flag remains set to false. This prevents the watchdog loop on lines 336-346 from running until after the onSecured function is called and the _isDeviceConnected flag is set to true.

For various reasons that are apparently more common in iPhones versus Android devices, the establishment of encryption is more likely to not complete, which would leave the nRF device BLE stack in a hung state.

To address this potential for a hung state I've implemented a timeout (BLE_SECURITY_TIMEOUT_MS) on the call to onSecured of 15 seconds, so that if a BLE connection is established via onConnect without the subsequent call to onSecured within that time, then disconnect is called, allowing the device to return to an advertising state and allow further connection attempts.

I have tested this patched firmware on a RAK 4631 board and it's been stable without any BLE issues for the past 24 hours.

[ipduffy]

Flashing this firmware to my test board now and I'll report back if there are any issues.

[ipduffy]

BLE connection has been stable on my device for the last 3 days.

[ipduffy]

Fixes #2213

[ipduffy]

My companion node has been stable BLE-wise for three weeks. No issues.

[dotspencer]

Any chance this could be reopened and considered for merging?

I've seen this failure on two different RAK 4631 companion nodes running v1.16.0 when connecting with iOS app. Same symptoms as #2213. Looks like the diff still applies cleanly to current HEAD.

@ipduffy did you hit any issues in testing, or was there some other reason this was closed?

[ipduffy]

I didn't run into any issues and in fact I'm still running my modified firmware on my wisblock today. It's working great. I closed the PR because of the recent blog post about vibe coding and how the zeitgeist seemed to be anti-AI (https://blog.meshcore.io/2026/04/23/the-split). I used Claude code to find this bug and also to implement some of the fixes. I am a C/C++ developer with some embedded programming experience, mostly on ESP32 boards, but I fully understood the bug and the fix that Claude proposed and implemented. But if the team is against any AI related code then I thought it best to close the PR and let this issue be fixed more organically.