[ryanbr]

Reported in #1997 by @semoi: a WHOOP 4.0 reconnects, the strap sends nothing, and after four cycles NOOP
pauses auto-reconnect and shows the re-pair guide. They had been re-pairing and rebooting several times a
day on that advice.

What the log actually shows

link	MTU	inbound
gen=1	247 (status=0)	6 frames / 26 bytes
gen=2	23 (status=4)	0 frames
gen=3	23 (status=4)	0 frames

Every re-attach is answered with a refused MTU exchange and sits at the 23-byte default, and on exactly
those links nothing arrives. The first bounce reports ACL-held, so the phone's stack still holds the
connection. NOOP re-attaches to a connection the strap is not on. No part of that is a strap declining to
pair.

NOOP cannot clear that connection, and this does not try to: gatt.close() is already called on teardown
and before each new connect, so NOOP is not the one holding it, and Android gives an app no way to drop a
connection it does not own.

Three changes

1. The pause stays, and the guide changes. The first version of this fix excluded these links from the
never-bonded give-up, reasoning that nothing was exchanged for the strap to refuse. That was wrong, and
only visible by asking what else would stop the loop: CLIENT_HELLO is 5/MG only, so on this reporter's
WHOOP 4.0 the other give-up never fires, and excluding them would leave the connect-drop-retry cycle
unbounded and draining both batteries. That is exactly the failure #982 exists to prevent. The pause is
correct. Only the explanation was wrong, so the guide swaps and the counting does not.

2. The guide and hint say the connection is held, rather than blaming the strap, and say re-pairing
will not change it, replacing the four re-pair steps for this state only. It still does not assert WHICH owner holds the link, because NOOP cannot see that: it names
both candidates and the action for each.

That restraint is the standard the neighbouring pausedHintHandshakeUnanswered already sets, which says
naming a cause is "a guess dressed as instruction" for an unanswered handshake. This branch meets that
bar rather than bending it: a refused MTU exchange with zero traffic is a positive observation that
something holds the link, not an inference from silence.

3. The MTU line reads as the failure it is. MTU negotiated: 23 (status=4) looks like a result and
requires the reader to know 23 is the fallback. This also revisits the call made in #2000 to leave MTU
status bare; on this log it is the single most diagnostic line.

Tests

+6. The predicate needs BOTH halves, so a refused exchange that still carried frames and a silent link
that negotiated fine are both left alone, the latter being the #1809 shape. A held link is pinned as
STILL counting toward the give-up, which is the correction above and the thing that keeps the loop
bounded. The guide is pinned as replacing the re-pair steps rather than repeating them, and as still
giving the user something to do.

One of these tests caught a real mistake while being written: it asserted the hint never contains the word
"re-pair", but the hint deliberately contains it in order to rule the action out. The assertion now pins
what was meant, which is that it never instructs one.

672 classes / 5693 tests, 0 failures.

Android-only: the refused MTU re-exchange is how this state presents on Android, and CoreBluetooth
negotiates MTU itself with no equivalent status to read.

Still open with the reporter: whether the official WHOOP app is installed, which would confirm the
owner of the held connection. The fix does not depend on the answer, since it describes what was observed
rather than asserting a cause.