[ryanbr]

Fixes #797. Refs #791, where this was reported as "finding 1" inside a battery report.

Two commits at deliberately different risk levels — read the second one carefully.

	Risk
e312f3a8 diagnostics — write status code, 4.0 response result/resp_seq	log output only
2eeb8e06 the fix — cancel a retry the completion callback disproved	behaviour change in the BLE write path

They are together because the fix depends on the first commit: its predicate sits beside writeStatusLabel
and its test asserts it. Splitting would have meant a stacked PR, which in this repo has already cost one
branch.

The bug

One GET_DATA_RANGE produced three CRC-valid responses whose strap-side sequence advanced (0x7e/0x7f/0x80)
while the origin-seq echo stayed 0x0a — so the strap received the command three times. Only ever after a
burst of busy-retries, never on quiet ticks. Reproduced three times in one session.

drainWriteQueue treats writeCharacteristicCompat returning false as proof of non-delivery. On this stack
the write was delivered anyway. The reason the retry is never called off is narrow:

pendingRetry   set on BUSY, cleared ONLY when the drain consumes it, or on reset

Nothing cleared it on a write-completion callback — and that callback is exactly the evidence that the
"refused" write landed. The completion released the in-flight slot, left the retry armed, and the retry sent
the frame again.

The fix

A completion for a frame still held for retry cancels it.

It cannot swallow a legitimate retry: pendingRetry is non-null only when the most recent attempt returned
BUSY, and the drain never starts a write while one is in flight, so no other outstanding command-channel write
could own that completion. A frame the stack truly refused produces no completion at all, so its retry
still fires — which is why the retry was left in place rather than removed. #77/#312 established that a
dropped TOGGLE_REALTIME_HR / SET_CLOCK / offload-ack silently breaks live HR, the clock, or the backfill,
and trading a duplicate for a silent loss would be worse.

Not airtight by construction. If the completion arrives after the retry has fired (12 ms base delay) the
duplicate is already out. This removes the observed case; it does not make duplication impossible.

Diagnostics (first commit)

• Which refusal occurred. writeCharacteristicCompat collapsed Android 13+'s int into a Boolean.
  ERROR_GATT_WRITE_REQUEST_BUSY (201) is documented as not initiated, so which code the stack returns is
  the difference between "safe retry" and "we just sent it twice". Now logged, with the command name.
• 4.0 result and resp_seq. The 5/MG path always exposed both; the 4.0 path exposed neither, so a 4.0
  log could not say whether a command succeeded. The reporter had to hand-decode result=0x00 from raw hex to
  learn their strap answers GET_EXTENDED_BATTERY_INFO with FAILURE rather than an empty success — the
  difference between "battery unreachable here" and "our decode is wrong". Verified against their real frames:
  answered GET_DATA_RANGE → resp_seq=0x0A, SUCCESS(1); empty extended-battery → resp_seq=0x22,
  FAILURE(0). Corroborated by GET_BATTERY_LEVEL having always read from payload[2..4], already skipping
  both bytes.

Testing

The decision is a pure companion predicate because the instance path cannot be unit-tested here — the
constructor needs a real Looper and Context and the project ships no Robolectric. That is the constraint
GattCrashSafetyTest documents and the pattern it follows: pin the pure decision the behaviour is built on.

Tests cover: a completion cancelling a held retry on both families' command channels; a completion with
nothing held being a no-op; a completion on another characteristic (or a null UUID) never cancelling, since
doing so would convert a duplicate into the silent loss #77/#312 is about; and the refusal-code labels.
The 4.0 decode tests use the reporter's real frames as vectors.

Statically verified: UUID literals in the test match the production constants byte for byte, the predicate and
writeStatusLabel are public companion members, no stale call site remains from the signature change, braces
balanced, Tools/i18n_audit.py --ci origin/main → exit 0.

Corrected during re-review

Two claims in the section above were wrong, and a third commit fixes them.

The safety argument was overstated. It said no other outstanding command-channel write could own a
completion, because the drain never starts a write while one is in flight. writeBondFrame is exactly such a
write — same characteristic, deliberately outside the queue, sets writeInFlight itself, never consumes
pendingRetry. Its ack proves nothing about a held frame, and acting on it would cancel a retry for a frame
that never left: the duplicate becomes the silent loss #77/#312 exists to prevent, which is worse. Now tracked
and excluded, with the flag consumed on the callback so a later completion cannot inherit it, and cleared in
reset() so a stale flag cannot suppress a legitimate cancellation next session.

The fix covers only WITH-response writes. A without-response write gets no completion callback — the drain
frees its own slot after a pacing gap — so there is no signal to act on. It happens to cover the reported
command and every case where a duplicate actually harms (GET_DATA_RANGE, SET_CLOCK, the historical acks,
haptics, RUN_ALARM are all withResponse = true), which I verified rather than assumed — but that is
fortunate, not by design, and the original text implied generality.

So precisely: a with-response command frame is no longer repeated when a completion proves the BUSY-refused
write was delivered, except where that completion belongs to the bond write. Without-response frames, and
completions arriving after the retry has fired, are unchanged.

What this needs before merge

Not run: the JUnit suite — no JDK on this machine and android.yml is disabled, so nothing compiled it.

More importantly, the fix wants a device test. It changes when a GATT write is repeated, and the failure
mode if the reasoning is wrong is a silently dropped command — worse than the duplicate it removes. Worth
confirming on hardware that live HR, the clock handshake and the backfill all still work across a reconnect,
ideally on a stack that produces busy-retries. @bhargav8963 offered to run probe builds and has the device that
reproduces it.