fix(cat): read MD6 back as DATA on an Elecraft, not RTTY

MD6 is FSK on a Kenwood and DATA on a K3/K4. kenwoodModeToADIF decoded the
digit unconditionally as RTTY, so OpsLog contradicted the mode it had just
set: SetMode writes MD6 for a digital mode on an Elecraft, then ReadState
parsed the IF frame back as RTTY.

A K3 running FT8 therefore showed RTTY in the status bar, logged its QSOs on
RTTY, and — through the shared CAT server — told WSJT-X/JTDX the rig sat in
RTTY while they had just asked for a data mode. Found in a K3 operator's log:
every cat:state line read mode=RTTY on 21.074 FT8, two lines after OpsLog's
own "MD6;".

The digit now resolves to the configured digital mode whenever MD6 means DATA
on this rig — the Elecraft backend, and the "DATA A - MD6" data-mode option
that exists for it. A plain Kenwood still reads MD6 as RTTY.

internal/cat/kenwood.go

@@ -291,7 +291,10 @@ func (k *Kenwood) ReadState() (RigState, error) {
 	s := RigState{Connected: true, Backend: "kenwood"}
 	k.curVFO = f.VFO
 	s.Vfo = f.VFO
-	s.Mode = kenwoodModeToADIF(f.Mode, k.digital)
+	// Both branches of SetMode that emit MD6 identify a K3/K4: the Elecraft
+	// backend, and the "MD6" data-mode option that exists for it. Decode the
+	// read-back the same way, or OpsLog contradicts the mode it just set.
+	s.Mode = kenwoodModeToADIF(f.Mode, k.digital, k.elecraft || k.dataMode == "data")
 	s.Rig = k.model
 
 	// IF reports the frequency of the VFO in USE (what the operator hears).
@@ -659,7 +662,11 @@ func kenwoodModeDigit(mode string, hz int64) byte {
 // Digital modes are indistinguishable from SSB over CAT — the rig only knows
 // it is on USB — so the operator's configured digital mode is used, exactly as
 // the other backends do.
-func kenwoodModeToADIF(d byte, digital string) string {
+//
+// md6IsData says whether MD6 means DATA on THIS rig — true for an Elecraft
+// (the K3/K4 backend, and the "MD6" data-mode option that targets it), false
+// for a plain Kenwood. See below.
+func kenwoodModeToADIF(d byte, digital string, md6IsData bool) string {
 	switch d {
 	case '1':
 		return "LSB"
@@ -672,6 +679,15 @@ func kenwoodModeToADIF(d byte, digital string) string {
 	case '5':
 		return "AM"
 	case '6', '9':
+		// One digit, two meanings. On a Kenwood MD6/MD9 is FSK/FSK-R; on an
+		// Elecraft it is DATA / DATA-REV — and DATA is precisely what SetMode
+		// puts a K3/K4 into for FT8. Reading it straight back as RTTY meant a K3
+		// running FT8 reported RTTY: the QSO was logged on the wrong mode, and
+		// the shared CAT link told WSJT-X/JTDX the rig sat in RTTY while they had
+		// asked for a data mode.
+		if md6IsData {
+			return digital
+		}
 		return "RTTY"
 	}
 	return ""

internal/cat/kenwood_test.go

@@ -141,8 +141,23 @@ func TestKenwoodModeToADIF(t *testing.T) {
 		{'0', ""}, // unknown → say nothing rather than guess
 	}
 	for _, c := range cases {
-		if got := kenwoodModeToADIF(c.d, "FT8"); got != c.want {
+		if got := kenwoodModeToADIF(c.d, "FT8", false); got != c.want {
 			t.Errorf("kenwoodModeToADIF(%q) = %q, want %q", c.d, got, c.want)
 		}
 	}
 }
+
+// On a K3/K4 the same digits mean DATA / DATA-REV, not FSK — and DATA is what
+// OpsLog itself sets for FT8. Decoding them as RTTY logged a K3 running FT8 on
+// the wrong mode and told the shared-CAT clients the rig was in RTTY.
+func TestKenwoodModeToADIFElecraftData(t *testing.T) {
+	for _, d := range []byte{'6', '9'} {
+		if got := kenwoodModeToADIF(d, "FT8", true); got != "FT8" {
+			t.Errorf("kenwoodModeToADIF(%q, elecraft) = %q, want %q", d, got, "FT8")
+		}
+	}
+	// Everything else is unaffected by the Elecraft dialect.
+	if got := kenwoodModeToADIF('2', "FT8", true); got != "USB" {
+		t.Errorf("kenwoodModeToADIF('2', elecraft) = %q, want USB", got)
+	}
+}