[ryanbr]

The second false bond, from the 30 Aug 22:47 capture. Unlike the first one this is not a mis-attributed completion — the completion really is the hello's. The error is what was concluded from it.

What the capture shows

Three lines, one link, two seconds apart:

22:46:31  CLIENT_HELLO outcome: acked by fd4b0002 after 5ms status=GATT_SUCCESS(0)
22:46:31  [connection] bondState encryptedBond family=whoop5 (CLIENT_HELLO acked)
22:46:33  bond state poll: BOND_NONE

The app displayed "Bonded, streaming." for that link — on a strap an HCI capture already shows answering SMP Pairing Not Supported, where an encrypted bond is not merely absent but impossible.

The confusion

A write completion says the stack finished the write. Encryption is a property of the link, and on Android the only thing that attests it is the OS bond state. The ack branch treated the first as proof of the second.

They are now recorded separately:

• encryptedBond waits for something that actually attests encryption — the OS bond state, or the strap's own BLE_BONDED event
• the completion still drives the handshake: subscribe the puffin chars, clock the strap, offload. All of that needs the strap to be listening, not the link to be encrypted

That split is deliberate and is the useful half: it keeps the only path that has ever plausibly led to history on this strap, while dropping the claim that was false.

The other claims in that branch

Everything asserting something about the strap's willingness to bond is gated on real encryption now: noteGenuineBond ("this strap bonds fine"), clearPairingHint, staleDirectFailures, the deferral run, and the hello-override budget.

Clearing those on an unencrypted completion is how a strap that has never bonded gets recorded as one that bonds fine — and it retires the very counters that exist to notice it never did. That is a self-erasing bug: the more it fires, the less evidence survives that it fired.

cancelBondWatchdog stays unconditional. The hello is answered either way and there is nothing left to time out.

Timing is diagnostic, never a gate

Across 41 captures the hello outcome is starkly bimodal:

outcome	count
"acked" in 0ms	1
"acked" in 4ms	3
"acked" in 5ms	1
"acked" in 7ms	3
no callback, ~3150ms	hundreds

Nothing in between, and 0ms cannot be a round trip. The line points at this when the elapsed is under one connection interval, because it is the clearest evidence in the set that the callback came from the local stack rather than the strap.

It decides nothing. A peripheral may answer inside the same connection event, so a fast round trip is unusual rather than impossible, and a strap that genuinely bonds must never have its bond rejected for being quick. The gate is the OS bond state; the timing is a pointer for whoever reads the capture next.

Android-only on purpose

No Swift twin here. CoreBluetooth exposes no bond or link-encryption state at all, so Apple has nothing to supply — a shared helper would be handed a constant false and would suppress bonds that are genuine there. The gap is real on Apple too; it cannot be closed the same way, and saying so beats a twin that is wrong.

Verification

• 4898 tests, 0 failures
• lintVitalFullRelease, doc-comment lint, i18n --ci clean
• staging 391 / iOS 272

Related to #1635.