fix: CI-V frames read at the wrong offset decoded as plausible frequencies

From F4JND's log: a rig sitting on 145.550 MHz FM produced status lines reading
16445550000, 8364550000, 5817408364 and 12640 Hz between good readings — the last
of those even resolved to a 6 cm band.

BCDToFreq treated the nibbles 0x0A..0x0F as the digits 10..15, so a byte stream
that had lost frame sync still decoded into a number. The same log shows why sync
was lost: PTT round trips timing out and a scope stream the rig kept rejecting
(0x27), both competing with the poll on one serial line.

Non-decimal nibbles are now refused. Each caller keeps its last good value rather
than publishing noise: the frequency reader returns an error, the sub-VFO reader
returns not-ok, and the scope keeps its previous edges. Garbage that LOOKS like a
frequency is worse than a refused frame — it reaches the display, the band slots
and eventually the log, and it is the operator who then has to disprove it.

The test builds its fixture with FreqToBCD rather than by hand, because my
hand-written one was byte-reversed and the test caught it.

This does NOT explain the white screen that was also reported, and I have not
claimed it does: it removes one source of absurd values reaching the UI, which is
worth doing on its own evidence.

internal/cat/xiegu_test.go

@@ -76,8 +76,9 @@ func TestXieguFrequencyEncoding(t *testing.T) {
 		if len(b) != 5 {
 			t.Fatalf("FreqToBCD(%d) produced %d bytes, want 5", hz, len(b))
 		}
-		if got := civ.BCDToFreq(b); got != hz {
-			t.Errorf("round trip %d → % X → %d", hz, b, got)
+		got, ok := civ.BCDToFreq(b)
+		if !ok || got != hz {
+			t.Errorf("round trip %d → % X → %d (ok=%v)", hz, b, got, ok)
 		}
 	}
 }