SWR TX halt can fire on a GOOD match: Yaesu meter nibble looks inverted before normalization

Found while investigating the 1-3s TX cutoff (fixed in #95). Separate latent bug, only affects operators who enable SWR protection (off by default):

• The first in-TX meter poll lands ~2s after key-down (START_QUERY_FREQ_DELAY/QUERY_FREQ_TIMEOUT = 2000ms), so a bogus SWR reading halts the image right at the start.
• Yaesu2Rig.java (~lines 97-108): the comment says the SWR nibble is 0-C with 0 = high SWR (inverted scale), but the code does swr = (data[1] & 0xF0) >> 4; notifyMeterData(alc*17, swr*17) with no inversion. If the comment is right, a healthy 1:1 match normalizes to ~200 (> threshold 120 ≈ 3:1) and trips MeterProtectionController.haltForSwr() → sstvTransmitter.cancel(false) — while a genuine SWR fault (nibble 0) never halts. Same pattern in Yaesu2_847Rig.java.
• Rigs also normalize SWR to 0-255 with very different curves (Kenwood min(swr*8,255), Elecraft swr*4, Icom raw BCD), so the single fixed threshold is easy to trip spuriously on some hardware even where the scale isn't inverted.

Suggested fix: verify the Yaesu nibble direction on real hardware (debug.log now records every reading: MeterProtection: SWR reading swr=N threshold=T -> HALT/ok), invert where needed, and consider requiring 2 consecutive over-threshold readings before halting so a key-down transient can't kill an image.

🤖 Generated with Claude Code

Start with the SWR parsing and normalization in Yaesu2Rig.java around lines 97-108, then compare the corresponding logic in Yaesu2_847Rig.java and the halt path in MeterProtectionController.haltForSwr(). Review debug.log readings from real hardware to verify the nibble direction and threshold behavior; done means healthy matches no longer halt transmission while genuine SWR faults still do.