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_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)
+	}
+}