feat(dvk): key the DATA input, not the microphone

From a TS-590SG report: the voice keyer played through the rig's USB
codec and the radio transmitted silence. Its manual says why — 'TX P1,
0: SEND (normal transmission using the MIC input), 1: DATA SEND
(ACC2/USB input)' — and OpsLog only ever sent the bare TX, so the radio
dutifully opened a front microphone nobody was speaking into.

An option on the audio page, shown for CAT keying, says where the
keyer's audio actually arrives; the manager routes it to a backend that
draws the distinction and falls back to the ordinary key for every rig
where one PTT is all there is. Test PTT goes down the same path, so it
tests what will happen rather than something adjacent.

internal/cat/kenwood.go

@@ -632,6 +632,28 @@ func (k *Kenwood) SetPTT(on bool) error {
 	return k.write("RX;")
 }
 
+// SetPTTData keys the transmitter on the DATA input: TX1 on a TS-590, which is
+// ACC2/USB rather than the front microphone. The radio's own manual is explicit
+// that the parameter chooses the input — "0: SEND (normal transmission using
+// the MIC input), 1: DATA SEND (ACC2/USB input)" — so a voice keyer playing
+// into the rig's USB codec has to say TX1 or it transmits dead air while the
+// radio listens to a microphone nobody is speaking into.
+//
+// Unkeying is the same RX either way; there is no data-flavoured stop.
+func (k *Kenwood) SetPTTData(on bool) error {
+	k.mu.Lock()
+	defer k.mu.Unlock()
+	if k.port == nil {
+		return fmt.Errorf("kenwood: not connected")
+	}
+	k.tx = on
+	if on {
+		k.txAt = time.Now()
+		return k.write("TX1;")
+	}
+	return k.write("RX;")
+}
+
 func (k *Kenwood) write(cmd string) error {
 	if k.port == nil {
 		return fmt.Errorf("kenwood: not connected")