[ryanbr]

The loop

A WHOOP 5/MG whose CLIENT_HELLO is never answered reconnects forever. From a field capture, eight consecutive cycles:

Disconnected (status=22); reconnecting directly in 3s (attempt 1, held 4s)
Disconnected (status=22); reconnecting directly in 3s (attempt 1, held 4s)
… ×8, one every ~11 seconds

Every one logs attempt 1 — the counter resets each cycle, so there is no backoff. It hammers the strap indefinitely, draining both batteries.

Why the existing give-up couldn't see it

The machinery already exists and works — it fired twice earlier the same day. Its gate is the first line of noteBondRefusalForPairingHint:

if (!isInsufficientAuthStatus(status)) return

It counts a failure only when the disconnect status is INSUFFICIENT_AUTHENTICATION(5) or INSUFFICIENT_ENCRYPTION(15). An unanswered handshake presents as a plain local terminate (22), so the streak never incremented and the give-up never latched.

Two observations mean the same thing for the purpose of stopping: the strap answered the bond write with a refusal, or it never answered at all.

The part I want reviewed most

The two signals are carried separately rather than merged, because only one of them supports naming a cause.

PAIRING_HINT_TEXT and pausedHint() both tell the user their strap is "still held by the official WHOOP app" and instruct them to close it and forget the device. That is well founded when the strap actively said no. It is an unfounded guess when the strap simply went quiet — and delivered as an instruction, an unfounded guess is worse than saying less, because the user has no way to know it might be irrelevant.

So an unanswered handshake gets a hint that describes what was observed, offers the one action that is definitely theirs, and asserts nothing about why:

NOOP stopped retrying because the secure handshake with your strap never completes: the strap does not answer, and the link drops a few seconds later. Auto-reconnect is paused so it stops draining both batteries. Tap Connect to try again, and if it keeps happening please share your strap log.

The over-threshold pairing guidance stays auth-only. There is a test asserting the new hint does not contain "official WHOOP app" or "Forget This Device".

What it does not do

This does not make the strap bond. It stops NOOP hammering one that cannot, and replaces a silent 11-second cycle with an honest paused state. Why the handshake goes unanswered is still open — #1639's bond-state trace is what should answer that.

Verification

• Counted only when the status is not an auth rejection, since those already reach the same accounting from onCharacteristicWrite; counting a cycle twice would trip the give-up at half the intended streak.
• compileFullDebugKotlin clean; full com.noop.ble suite (438 tests) green.
• 6 tests on the pure rule, including the over-reach guard — an ordinary disconnect with neither signal must not accrue, or a healthy strap would eventually pause itself — and the WHOOP 4.0 exclusion.
• doc_comment_lint and i18n_audit --ci main clean, gated on rather than run alongside.
• BLE behaviour change: needs app-build, and a real-strap capture to confirm the loop actually stops. Compile-success proves nothing about connection behaviour.