fix(ble): park the bond-loop pause's standing connect once the link is down

[DX23876]

Refs #1539

What was wrong

The #1544 standing-connect escape never armed on Apple. Every site that trips the bond-loop pause runs inside didDisconnectPeripheral before that handler sets state.connected = false, and standingConnectWhilePausedIfDue read state.connected right there. The dying link still counted as up, so shouldStandingConnectWhilePaused refused and nothing was parked. The paused branch further down the same handler then refused too, because the trip had just started the 10-minute floor. With the app backgrounded nothing else re-arms it, so the strap stayed disconnected until the app was next opened, which is the symptom #1539 reported.

Seen on a WHOOP MG (fw 50.41.1.0): two connection timeouts within 11 s tripped the #617 detector, the log never printed "parking a standing connect", and the strap stayed disconnected for 49 minutes while a workout was being recorded, until the app was reopened.

Android never had this: its twin posts the check to the handler, so it runs after handleDisconnect has finished the teardown.

Change

• Swift: standingConnectWhilePausedIfDue evaluates on the next main-queue turn, as the Kotlin handler.post does. This covers all four call sites at once.
• Both platforms: the paused-disconnect line said "strap keeps refusing to pair" for every pause, including the Today: Steps and Calories tiles get their trend sparkline (#616) #617 drops and the Stop the capture check reading its own output as evidence #971/Engine Result fields are computed and never read — a sweep, plus 'time in high stress' and a CircadianEngine domain mismatch #982 pairing that never finished, where no refusal was observed. The cause is now recorded with the latch (BondLoopPauseCause, same phrases on both platforms): "strap keeps refusing to pair", "pairing never finished" or "the link dropped within seconds of pairing N times in a row".

Verification

• BondLoopPauseParkingTests drives the real call order (trip while the link still reads connected, then tear down). It failed before the change and passes after it.
• The wording is pinned with identical strings on both platforms (BondLoopPauseParkingTests, BondLoopPauseCauseTest).
• macOS StrandTests and the Android com.noop.ble unit tests pass; the iOS target builds.
• Hardware: the stranding was observed on an MG in a field log. The fixed build has not yet tripped the pause on a real strap, so the parked connect after a trip is verified by the test only.