fix: Yaesu Connect leaked the serial handle on every reconnect

Connect assigned a fresh handle to y.port without closing the one it already
held. It is called again on every reconnect, so a rig that fails to answer leaks
one handle per attempt — every few seconds, indefinitely.

Windows opens a serial port EXCLUSIVELY, which makes this visible as "yaesu: open
COM7 @ 9600 baud: Serial port busy" in an operator's log: OpsLog was competing
with itself for the port.

This is a real defect found while reading the reconnect loop, but I want to be
straight about its limits: it does NOT explain the seven minutes of "ID query
failed — timeout" in the same log, where the port opened and the rig stayed
silent. That one is still open, and the operator alternates between two separate
radios (a TCI SDR and the Yaesu) rather than sharing one port, so a conflict
between backends is not the explanation either.

internal/cat/yaesu.go

@@ -135,6 +135,17 @@ func (y *Yaesu) Connect() error {
 	if y.portName == "" {
 		return fmt.Errorf("yaesu: no serial port configured")
 	}
+	// Close any handle we still hold before opening another.
+	//
+	// Connect is called again on every reconnect, and it used to overwrite y.port
+	// with a fresh handle and leak the old one. Windows opens a serial port
+	// EXCLUSIVELY, so a leaked handle makes the next open fail with "Serial port
+	// busy" — seen in the field — and the retry loop then leaks one handle per
+	// attempt, once every few seconds, for as long as it keeps failing.
+	if y.port != nil {
+		_ = y.port.Close()
+		y.port = nil
+	}
 	p, err := serial.Open(y.portName, &serial.Mode{BaudRate: y.baud})
 	if err != nil {
 		return fmt.Errorf("yaesu: open %s @ %d baud: %w", y.portName, y.baud, err)