Don't let the body-location probe's detail line contradict its own verdict (#690)

[ryanbr]

Follow-up from the #913 review — found by sweeping the other probes for the same defect class, not reported.

The report contradicts itself

A bare-stub run prints both of these:

Verdict: opcode 84 answered with a bare stub — ambiguous
...
No payload beyond the command byte (bare stub) — no body-location data on this firmware

The verdict is right. The detail line settles what the verdict just called unsettled — and it is the line that reads like a finding.

One reply carrying no payload does not distinguish a firmware without body-location data from one that needs the strap worn, in a determinate position, or asked with an argument this probe does not send. The file's own enum has UNKNOWN(0) and NOT_CONCLUSIVE(128), so the firmware explicitly models "cannot tell right now" — precisely the reading the detail line ruled out.

Same class as #913 and #914: a probe asserting a conclusion the run's inputs could not support, in the sentence someone pastes into an issue.

Both platforms, and it is a shared defect

I checked whether this was a divergence and it is not — Swift and Kotlin carry the byte-identical string, so both are reworded:

No payload beyond the command byte (bare stub) — this reply carried no body-location data, which is not the same as the firmware having none (see the Verdict above)

The tests could not have caught it

Both existing bare-stub tests asserted only text.contains("bare stub"), which passes under either wording. They now assert the over-claim is absent and that the verdict and the hedge are both present. That is the difference between a test that pins behaviour and one that happens to pass.

The golden parity lock is unaffected — it pins a payload-bearing frame, so the bare-stub branch was never inside it. I verified that rather than assuming.

[ryanbr]

Re-reviewed before merge, specifically the two claims a reader would poke at.

The new wording survives the one path where the verdict is not "ambiguous". A 5/MG reply with result=UNSUPPORTED(3) and no payload prints the REJECTED verdict and then this detail line. "See the Verdict above" is still correct there — the verdict carries the decisive information, and the detail line's hedge defers to it rather than fighting it. So the line is safe under all three verdict branches, not just the one the test pins.

The sweep's one near-miss, checked and left alone. ExtendedBatteryProbe has a similar-shaped line — No payload beyond the command byte (bare stub) — no data over the battery event; opcode 98 may be an unknown-command ack on this firmware. Different defect profile: the first clause describes this reply (it adds nothing beyond what the BATTERY_LEVEL event already carries), and the firmware clause is explicitly hedged with "may be". That is the honest shape already, on both platforms, so it stays.

Also verified mechanically: the replacement string is byte-identical Swift↔Kotlin, and the Kotlin golden lock (like the Swift one) pins an ACCEPTED payload-bearing frame, so the bare-stub branch sits outside both locks — the strengthened bare-stub tests are the only coverage of this line, which is why they now assert absence of the over-claim rather than presence of a substring both wordings contain.