[ryanbr]

Follow-up to #1742, caught on the first field capture taken with any of it in mind. The probe as merged would essentially never have run.

The gap

shouldProbeUnbondedOffload requires a link carrying no CLIENT_HELLO, and that gate is right — a subscribe refusal on a link the bond watchdog is about to bounce is unattributable, which is the ambiguity this whole thread has been paying for since June.

But the probe is only scheduled from the two no-hello branches, and on this strap neither is reached in practice:

• across 41 field captures, the suppression latch fired in three, all on 26 Aug, and never since
• the explicit-bond deferral yields after its first connect by design (ble: stop the CLIENT_HELLO from knocking a working 5/MG link off every 5s #1642), so every link after that writes a hello

In the 22:21 capture the pull-to-refresh reaches the offload and is turned away by exactly this gate, twice in three seconds:

22:20:16  Backfill: deferred — connect handshake not done yet
          (family=WHOOP5 didBond=false helloWrittenThisLink=true bondRequestedThisLink=true deferrals=1)
22:20:18  Backfill: deferred — ... deferrals=2
22:20:18  CLIENT_HELLO outcome: NO write callback after 3080ms
22:20:18  Disconnected (status=22)

helloWrittenThisLink=true on every one of those links. The probe would have waited behind a state the app almost never enters.

The fix

Not to loosen attributability — that is what makes the answer worth having.

These are mutually exclusive experiments. "Does the hello work" and "is the hello needed at all" cannot both be asked of one link, because asking the first is what destroys the second's link. Turning the switch on is choosing the second question, so it now supersedes the handshake for that connect — the explicit pairing request as well as the hello.

Placed ahead of both, not beside the hello decision: the deferral branch returns early, so a probe scheduled after it never runs. That ordering is the bug, restated.

What still wins

Pressing Connect still gets the handshake, exactly as it overrides the suppression latch today. An explicit request for one experiment must never be answered with a different one.

Narrow otherwise: 5/MG only, never on a strap that has already bonded (that one reaches the offload the proven way), default off.

Log honesty

The new line says the hello is absent by choice — an absent hello reads identically to one that failed silently, which is precisely what made #1635 unreadable for eleven weeks.

It also names the explicit-bond switch when that is on too. The two do not conflict fatally, but a pairing in flight makes a subscribe refusal unattributable to the strap, so the probe declines to latch it and the capture is weaker for no gain. Better to say so than to let someone run both and get a mushy answer.

Also: versionCode in the strap-log header

Build identity has been ambiguous three times in two days. Twice it cost a detour reasoning about which binary a capture came from, and dating the 22:21 log depended on noticing that probe lines were absent. One field ends that.

Verification

• 4893 tests, 0 failures
• lintVitalFullRelease, doc-comment lint, i18n --ci clean
• staging 390 / iOS 271
• still not hardware-validated — that is what the build is for

Related to #1635 and #1742.