fix: serial CAT keyed the radio on connect; Xiegu can key on RTS/DTR

Reported on a Xiegu G90. With the blue programming cable — three wires, no
modem lines — CAT works perfectly. Behind a DE-19, which carries audio, CAT and
PTT, the radio went into transmit the moment OpsLog connected and stayed there.

Windows raises DTR and RTS when a serial port is opened, and the DE-19 reads
them as PTT; Xiegu's own documentation asks for both low. The CI-V backend has
dropped them since it was written, for the same reason on Icom rigs with USB
SEND mapped to a line. Xiegu, Yaesu and Kenwood did not. They do now.

The second half of the report: WSJT-X through OpsLog's rigctld decoded fine and
never transmitted. Nothing was broken in that chain — set_ptt reaches the
backend, which sends the CI-V PTT command, which a G90 ignores. That is why
Xiegu keys on a hardware line instead. The backend can now do that: Settings →
CAT → Xiegu → how the rig is keyed (CI-V / RTS / DTR).

Untested here — no G90 in reach. The operator who reported it offered to try.

internal/cat/xiegu.go

@@ -56,6 +56,9 @@ type Xiegu struct {
 	// asking every cycle — a Xiegu that has no split must not cost a timeout per
 	// poll, which would slow the whole loop to a crawl.
 	splitSupported bool
+	// pttLine is "", "rts" or "dtr": which hardware line keys the rig, when the
+	// CI-V command does not.
+	pttLine string
 }
 
 func NewXiegu(portName string, baud int, addr int, digital string) *Xiegu {
@@ -74,6 +77,14 @@ func NewXiegu(portName string, baud int, addr int, digital string) *Xiegu {
 	}
 }
 
+// SetPTTLine selects the hardware line that keys this rig: "rts", "dtr", or ""
+// for the CI-V command. Set before Connect.
+func (x *Xiegu) SetPTTLine(line string) {
+	x.mu.Lock()
+	x.pttLine = strings.ToLower(strings.TrimSpace(line))
+	x.mu.Unlock()
+}
+
 func (x *Xiegu) Name() string { return "xiegu" }
 
 func (x *Xiegu) Connect() error {
@@ -87,6 +98,20 @@ func (x *Xiegu) Connect() error {
 		return fmt.Errorf("xiegu: open %s @ %d baud: %w", x.portName, x.baud, err)
 	}
 	p.SetReadTimeout(200 * time.Millisecond)
+	// Deassert DTR and RTS.
+	//
+	// Windows raises both when a serial port is opened, and a great many
+	// interfaces read them as PTT: a Xiegu G90 behind a DE-19 goes into
+	// transmit the moment OpsLog connects and STAYS there — Xiegu's own
+	// documentation asks for RTS and DTR low. The same applies to an Icom with
+	// USB SEND mapped to a line (which is why the CI-V backend has done this
+	// from the start) and to any rig keyed by a home-made cable.
+	//
+	// PTT on this backend is a CAT command, so neither line should ever be
+	// asserted here. A station keying by RTS/DTR configures that separately,
+	// on its own port.
+	_ = p.SetDTR(false)
+	_ = p.SetRTS(false)
 	x.port = p
 	x.splitSupported = true
 
@@ -177,12 +202,25 @@ func (x *Xiegu) SetMode(mode string) error {
 	return x.send(civ.CmdSetMode, m)
 }
 
+// SetPTT keys the transmitter, by CI-V or by a hardware line.
+//
+// A G90 does not transmit on the CI-V PTT command. Xiegu's own interfaces key
+// on RTS or DTR instead — the DE-19 does exactly that — which is why the line
+// can be selected here. Without it, WSJT-X talking to OpsLog's rigctld server
+// decoded perfectly and never transmitted: the command left, the radio ignored
+// it, and nothing in the chain was wrong enough to complain.
 func (x *Xiegu) SetPTT(on bool) error {
 	x.mu.Lock()
 	defer x.mu.Unlock()
 	if x.port == nil {
 		return fmt.Errorf("xiegu: not connected")
 	}
+	switch x.pttLine {
+	case "rts":
+		return x.port.SetRTS(on)
+	case "dtr":
+		return x.port.SetDTR(on)
+	}
 	v := byte(0x00)
 	if on {
 		v = 0x01