docs: FTDX10 confirmed — no CAT keying, the serial DTR keyer is the way

Tested on the radio: DAKY does not help, KY is refused whatever PC KEYING is set
to, and the "Serial port (DTR=CW / RTS=PTT)" engine on the second COM port keys
correctly. So my earlier "try DAKY first" was wrong, and the order is now the
other way round: name what works, mention the model that refuses.

The KY engine stays. It is documented for the FTDX101 / FT-991A / FT-710 family
and costs nothing to keep — a rig that refuses it now says so in one clear
sentence instead of transmitting nothing for no stated reason.

internal/cat/yaesu_cw.go

@@ -13,12 +13,14 @@ package cat
 //
 // The leading SPACE after KY is part of the command, not padding.
 //
-// Observed on an FTDX10 (2026-07-29): it answered "?;" to both KY; and
-// KY <text>; with PC KEYING left at its default. That rig's CW menu offers
-// DAKY / RTS / DTR, and KY is the CAT route, so DAKY is the setting that should
-// enable it — untested at the time of writing. When the rig refuses, the error
-// says so and names both that setting and the serial line keyer as the fallback,
-// rather than failing silently.
+// CONFIRMED on an FTDX10 (2026-07-29): it refuses this outright, answering "?;"
+// to both KY; and KY <text>; — including with PC KEYING on DAKY, the obvious
+// candidate, which does NOT help. That model keys from a PC only through the DTR
+// line of its second (standard) COM port, which is OpsLog's "serial" engine and
+// is confirmed working.
+//
+// The code stays because KY is documented for the FTDX101 / FT-991A / FT-710
+// family. On a rig that refuses it, the error now names the route that works.
 //
 // STOP is the other uncertain half: Yaesu documents no buffer-clear, see StopCW.
 
@@ -122,14 +124,14 @@ func (y *Yaesu) drainCWReply() error {
 			frame := strings.TrimSpace(string(buf[:i+1]))
 			buf = buf[i+1:]
 			if frame == "?;" {
-				// Observed on an FTDX10 (2026-07-29). Its PC KEYING menu offers DAKY,
-				// RTS and DTR: KY is the CAT route, so DAKY is the setting that would
-				// enable it — worth naming, since the alternative costs the operator a
-				// second COM port. If DAKY does not help, the line keyer does.
-				return fmt.Errorf("the radio refused the CW keying command (it answered \"?;\" to KY). " +
-					"Set PC KEYING to DAKY in the rig's CW menu; if that does not help, use the " +
-					"\"Serial port (DTR=CW / RTS=PTT)\" keyer on the rig's other COM port (the standard " +
-					"one) with PC KEYING set to DTR, while CAT keeps the enhanced port")
+				// An FTDX10 refuses KY whatever PC KEYING is set to — DAKY included,
+				// tested on the radio 2026-07-29. The message therefore points
+				// straight at what works, rather than at a setting that will not
+				// help.
+				return fmt.Errorf("this radio does not accept CW over CAT (it answered \"?;\" to KY). " +
+					"Switch the keyer engine to \"Serial port (DTR=CW / RTS=PTT)\" on the rig's OTHER " +
+					"COM port — the standard one, CAT keeping the enhanced one — with PC KEYING set " +
+					"to DTR in the rig's CW menu")
 			}
 			debugLog.Printf("yaesu cw: rig answered %q to KY — ignoring", frame)
 		}