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/yaesu.go

@@ -150,6 +150,20 @@ func (y *Yaesu) Connect() error {
 	if err != nil {
 		return fmt.Errorf("yaesu: open %s @ %d baud: %w", y.portName, y.baud, err)
 	}
+	// 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)
 	p.SetReadTimeout(300 * time.Millisecond)
 	y.port = p