fix: do not report a Yaesu as connected when it answers nothing

The seven minutes of reconnects in the operator's log turned out to be the radio
switched off — no defect. But the log said otherwise:

  20:14:42 yaesu: ID query failed (timeout) — continuing…
  20:14:44 yaesu: connected on COM7 @ 38400 baud, model="FTDX101D"

Opening the port was treated as connecting, and the model name was left over from
the previous session, so a powered-down rig produced a line claiming it was
connected as a named model. That is what sent me looking for a software fault.

Connect now tracks whether ANY probe answered. If none did, it clears the stale
model, says so in terms an operator can act on — is it powered on, is the CAT
rate right — and returns an error so the reconnect loop keeps trying rather than
believing it succeeded.

internal/cat/yaesu.go

@@ -158,7 +158,9 @@ func (y *Yaesu) Connect() error {
 	// a reply impossible to attribute — we poll instead, so the traffic is ours.
 	_ = y.write("AI0;")
 
+	answered := false
 	if id, err := y.ask("ID;"); err == nil {
+		answered = true
 		code := strings.TrimSuffix(strings.TrimPrefix(id, "ID"), ";")
 		if name, ok := yaesuModels[code]; ok {
 			y.model = name
@@ -178,6 +180,7 @@ func (y *Yaesu) Connect() error {
 	// VS is a weaker substitute that an FTDX101 answers with the main VFO even
 	// when the operator has moved both RX and TX to sub.
 	if r, err := y.ask("FR;"); err == nil && strings.HasPrefix(r, "FR") {
+		answered = true
 		y.rxVFOCmd = "FR"
 		debugLog.Printf("yaesu: receive VFO is read through FR (answered %q)", r)
 	} else {
@@ -186,6 +189,7 @@ func (y *Yaesu) Connect() error {
 
 	for _, c := range []string{"ST", "FT"} {
 		if r, err := y.ask(c + ";"); err == nil && strings.HasPrefix(r, c) {
+			answered = true
 			y.splitCmd = c
 			debugLog.Printf("yaesu: split is read through %s (answered %q)", c, r)
 			break
@@ -194,6 +198,18 @@ func (y *Yaesu) Connect() error {
 	if y.splitCmd == "" {
 		debugLog.Printf("yaesu: neither ST; nor FT; answered — split will be reported as OFF. Send this log if the rig does have split.")
 	}
+	// A port that opens is not a rig that is there.
+	//
+	// The log used to announce "connected … model=FTDX101D" after every probe had
+	// timed out, with the model left over from the previous session — an operator
+	// whose radio was simply switched OFF got a line saying it was connected, and
+	// the real cause took a log study to find. Say what actually happened.
+	if !answered {
+		y.model = ""
+		debugLog.Printf("yaesu: %s opens at %d baud but the rig answers nothing — is it powered on, and is its CAT rate %d?",
+			y.portName, y.baud, y.baud)
+		return fmt.Errorf("yaesu: %s opened but the rig is not answering — check that it is switched on", y.portName)
+	}
 	debugLog.Printf("yaesu: connected on %s @ %d baud, model=%q", y.portName, y.baud, y.model)
 	return nil
 }