fix: split read (and set) backwards on a Yaesu reporting the TX VFO

Reported on an FTDX101: the panel showed split ON with the radio OFF, and the
reverse — while the same model behaved correctly for another operator, and an
FTDX10 was fine throughout. That pattern is the clue: one operator was on MAIN,
the other on SUB.

The two commands say different things and were read alike:

  ST is a split FLAG   — ST1 means split, whatever VFO is in use.
  FT names the TX VFO  — FT0 = transmit on A, FT1 = transmit on B.

Split is on when the rig transmits on a DIFFERENT VFO from the one it listens to.
Reading FT1 as "split" is therefore correct only on VFO A, and exactly inverted
on SUB. It is now compared with the current VFO.

Writing had the identical fault, and it was worse: sending FT1 for "split on"
while the operator listened on SUB CLEARED the split it was asked to set. Both
directions are pinned by tests over each VFO state.

internal/cat/yaesu.go

@@ -223,7 +223,7 @@ func (y *Yaesu) ReadState() (RigState, error) {
 	split := false
 	if y.splitCmd != "" {
 		if r, err := y.ask(y.splitCmd + ";"); err == nil {
-			split = yaesuSplitOn(r, y.splitCmd)
+			split = yaesuSplitFromReply(r, y.splitCmd, vfo)
 		}
 	}
 
@@ -396,18 +396,33 @@ func parseYaesuFreq(reply, prefix string) (int64, bool) {
 	return hz, true
 }
 
-// yaesuSplitOn reads the split reply for whichever command the rig answers.
+// yaesuSplitFromReply turns the split reply into a yes or no.
 //
-// ST is a split flag: ST1 means split. FT names the TX VFO: FT1 means transmit
-// on VFO B, which IS split when the operator is listening on A. The two are not
-// the same statement, which is why the command in use is remembered rather than
-// both being tried and merged.
-func yaesuSplitOn(reply, cmd string) bool {
+// The two commands say DIFFERENT things and reading them alike is a real fault,
+// reported on an FTDX101 (F4NBZ, 2026-07-29) where the panel showed split ON with
+// the radio OFF and the reverse:
+//
+//	ST is a split FLAG      — ST1 means split, whatever VFO is in use.
+//	FT names the TX VFO     — FT0 = transmit on A, FT1 = transmit on B.
+//
+// Split is on when the rig TRANSMITS on a different VFO from the one it is
+// LISTENING to. Reading FT1 as "split" is therefore only right for an operator
+// on VFO A: on SUB it is exactly inverted, which is why the same model behaved
+// correctly for one operator and backwards for another — one was on MAIN, the
+// other on SUB.
+func yaesuSplitFromReply(reply, cmd, vfo string) bool {
 	r := strings.TrimSpace(reply)
 	if !strings.HasPrefix(r, cmd) || len(r) < len(cmd)+1 {
 		return false
 	}
-	return r[len(cmd)] == '1'
+	d := r[len(cmd)]
+	if cmd == "ST" {
+		return d == '1'
+	}
+	// FT: compare the transmit VFO with the one being listened to.
+	txOnB := d == '1'
+	rxOnB := strings.HasPrefix(strings.ToUpper(vfo), "B")
+	return txOnB != rxOnB
 }
 
 // resolveYaesuVFOs turns the two frequencies plus the VFO and split flags into