fix: the FTDX10 refuses KY; — stop waiting on a status it will never send

The log settled it: the rig answers "?;" — its "unknown command" — to KY; and to
MG;. So the keyer status query cannot work on this model, and every send spent
four seconds waiting for an answer that was never coming.

"?;" is now recognised as what it is. A command refused once is never asked
again: models implement different subsets, and re-asking costs a 600 ms timeout
on every slow beat for a control that will never answer — which is also why the
panel felt sluggish.

Without a buffer status there is still a real constraint: one KY command carries
24 characters and the rig DROPS the rest silently. So the send is now paced by
how long the text takes to key, from PARIS timing at the rig's own speed. A long
macro goes out complete instead of losing its tail.

That leaves the question the log cannot answer: whether KY <text>; itself is
accepted. If the rig also replies "?;" to it, the CAT menu's PC KEYING setting is
the next suspect — but nothing in the code will be guessing at it.

internal/cat/yaesu_cw.go

@@ -18,6 +18,7 @@ package cat
 // Yaesu documents no way to clear the buffer, so see StopCW.
 
 import (
+	"errors"
 	"fmt"
 	"strings"
 	"time"
@@ -62,10 +63,48 @@ func (y *Yaesu) SendCW(text string) error {
 		if err != nil {
 			return err
 		}
+		// When the rig will not tell us how full its buffer is (an FTDX10 answers
+		// "?;" to KY;), pace the next piece by how long this one takes to key.
+		// Sending everything at once overruns the 24-character buffer and the rig
+		// silently drops the rest.
+		if len(msg) > 0 && y.cwStatusUnsupported() {
+			time.Sleep(yaesuCWDuration(chunk, y.keyerWPM()))
+		}
 	}
 	return nil
 }
 
+// cwStatusUnsupported reports whether this rig refused the KY status query.
+func (y *Yaesu) cwStatusUnsupported() bool {
+	y.mu.Lock()
+	defer y.mu.Unlock()
+	return y.unsupported["KY;"]
+}
+
+// keyerWPM is the speed the rig is keying at, for pacing. Falls back to a
+// middling 20 wpm when the rig does not report it: too slow only wastes a
+// moment, too fast overruns the buffer.
+func (y *Yaesu) keyerWPM() int {
+	y.mu.Lock()
+	defer y.mu.Unlock()
+	if y.panel.KeySpeed >= 4 {
+		return y.panel.KeySpeed
+	}
+	return 20
+}
+
+// yaesuCWDuration estimates how long a piece of text takes to key.
+//
+// PARIS timing: one word is 50 dit-lengths and a word is 5 characters, so a
+// character averages 10 dits and a dit is 1.2/wpm seconds.
+func yaesuCWDuration(text string, wpm int) time.Duration {
+	if wpm < 4 {
+		wpm = 20
+	}
+	ditMs := 1200.0 / float64(wpm)
+	return time.Duration(float64(len(text))*10*ditMs) * time.Millisecond
+}
+
 // StopCW aborts the message being sent.
 //
 // Yaesu documents no buffer-clear, so this drops the transmitter instead: TX0
@@ -95,12 +134,25 @@ func (y *Yaesu) waitCWBuffer(within time.Duration) error {
 			y.mu.Unlock()
 			return fmt.Errorf("yaesu: not connected")
 		}
+		if y.unsupported["KY;"] {
+			y.mu.Unlock()
+			return nil // this rig does not report buffer state — pacing covers it
+		}
 		r, err := y.ask("KY;")
-		y.mu.Unlock()
 		if err != nil {
-			debugLog.Printf("yaesu cw: KY status query failed (%v) — sending anyway", err)
+			if errors.Is(err, errYaesuUnsupported) {
+				if y.unsupported == nil {
+					y.unsupported = map[string]bool{}
+				}
+				y.unsupported["KY;"] = true
+				debugLog.Printf("yaesu cw: this rig does not answer KY; — pacing the send by keying time instead")
+			} else {
+				debugLog.Printf("yaesu cw: KY status query failed (%v) — sending anyway", err)
+			}
+			y.mu.Unlock()
 			return nil
 		}
+		y.mu.Unlock()
 		// Only an explicit "full" holds us back.
 		//
 		// The first version required the reply to be exactly "KY0;" at byte 2, and