[ryanbr]

The give-up worked, and was undone

A capture on 31 Aug (build 397, 5/MG, fw 50.41.1.0) has two disconnect bursts
sixteen hours apart, and the gap between them is the point — the link was
perfectly stable all night, so the strap is not what is unstable.

00:39:38 → 00:41:20    7 links, all ~10.8s   the unbonded offload probe
00:41    → 17:21      16 hours, zero disconnects
17:32:05 → 17:39:44   18 links, all   4.8s   the CLIENT_HELLO

The second burst should have ended itself. At 17:32:48 the give-up fired exactly
as designed:

Bond epitaph: the strap [6bf655fa] never acknowledged the secure handshake 5x in
a row, and the attempt is what drops the link - leaving the handshake off so live
heart rate keeps streaming. Tap Connect to try it again.
bond gaveUp refusals=5 (hello suppressed, staying connected)

Then 13 more CLIENT_HELLOs. CLIENT_HELLO suppressed for this strap — the
line printed when a hello is actually skipped — appears zero times in the
entire log.

Why

With "Ask Android to pair" on, the explicit-bond request cleared the suppression
latch. The comment there reasoned it was safe:

Cleared ONCE, here, rather than re-armed by "an OS pairing exists" — that
condition never goes away, so it would bypass the latch on every connect and
restore the unbounded loop for good.

It guarded the wrong recurrence. shouldRequestExplicitBond is bounded only by
alreadyRequestedThisLink, a per-link flag; on a strap answering SMP
"Pairing Not Supported" neither bond condition ever becomes true. So createBond
fires on every connect and the clear fired with it. The capture holds 18
pairing requests and 18 CLIENT_HELLOs — one of each on every link, which is
exactly the pairing helloDeferredByExplicitBond exists to forbid. The comment
describes its own effect and rules it out in the same breath.

It could not recover, either. recordRefusal() reports the crossing exactly once
and stays gaveUp until reset(), so the latch is written once per session.
A clear on a recurring event does not cost one link and self-correct — it costs
the latch permanently. The #1635 end state (live HR, handshake off, link stable)
was simply unreachable while that switch was on.

The change

The clear is removed. Recovery is the explicit Connect the epitaph already names,
cleared through clearPairingHintForUserConnect().

The encrypted-bond clear is deliberately not offered as an automatic
alternative: clearPairingHint() on a genuine bond lives inside the hello
write-completion callback, so a suppressed hello cannot reach it. Claiming it
would be the same overclaim the retirement line in #1761 had to be corrected for.
That costs nothing real — the latch only sets after five consecutive refusals, so
"latched, and pairing now works" requires something to have changed (new
firmware, the strap put into pairing mode as on @Zebsi235's MG), and a user who
has changed something taps Connect.

The pairing experiment is untouched: createBond still runs on every link. It
just no longer drags the hello along with it — which is exactly what
helloDeferredByExplicitBond says must never share a link:

Writing to the encrypted characteristic while a pairing is in flight is the
behaviour that has been dropping the link for eleven weeks, so doing both at
once would test nothing and reproduce the bug.

Tests

Two pins for the contradiction that produced this, one on each side:

• ExplicitBondTest — the request recurs on every link, so nothing may hang a
  once-only side effect off it.
• HelloSuppressionTest — the give-up reports its crossing once, so the latch is
  written once and a recurring clear is permanent.

A stale comment on an existing OS pairing does NOT permanently bypass the latch
called the pairing request the "self-limiting" alternative; it was not, and now
says so.

606 tests in com.noop.ble, zero failures on a forced clean run.
compileFullDebugKotlin, doc_comment_lint.py, i18n_audit.py clean.

What this does not settle

With the hello suppressed, createBond still runs once per link on a strap that
refuses SMP. Nothing in this capture says whether that alone is enough to keep a
link up, because the sixteen stable hours contained no connects at all. If the
next capture still shows a loop, that is the remaining cause and it will be
readable for the first time — with the hello finally out of the way.

Parity

Checked rather than assumed. Swift has the same BondRefusalGiveUp mirror and the
same latch (HelloSuppressionStore), and its three writes are all sound: the
release path (twin of Kotlin's forget-device clear), the give-up write, and one
clear gated on ClientHelloOutcome.isAck — an outcome, not a request. No twin
of this bug exists there, and could not: CoreBluetooth has no createBond, which
is why the offending clear is Android-only in the first place.

Android only. Refs #1635.