fix: RX and TX both on SUB is simplex, not split

Reported on an FTDX101: with RX and TX moved together to the sub VFO, OpsLog
showed split — and took the MAIN frequency as the transmit one, which would log
the wrong frequency.

ST is a bare flag. It says "split" without saying which VFO transmits, and this
rig raises it whenever the transmit VFO is the sub one, whether or not the
operator is also listening there. FT names the transmit VFO, so where the receive
VFO is known as well (FR), split is derived from the pair: they differ or they do
not. That is a fact about the rig's state rather than a flag whose meaning varies
by model.

The fix is therefore in the probe ORDER, not in the reading: FT is asked first
when FR answered, and ST stays the fallback for rigs that have neither. A test
pins the order and both halves of the trap — that FT gets this case right, and
that ST alone gets it wrong.

internal/cat/yaesu.go

@@ -187,7 +187,21 @@ func (y *Yaesu) Connect() error {
 		debugLog.Printf("yaesu: no FR; — falling back to VS for the receive VFO")
 	}
 
-	for _, c := range []string{"ST", "FT"} {
+	// Which command carries split — and the ORDER matters.
+	//
+	// ST is a bare flag: it says "split", not which VFO transmits. On an FTDX101
+	// with RX and TX both moved to SUB, the rig reports ST1 even though that is
+	// plain simplex on the sub VFO, and OpsLog showed split with the main
+	// frequency as TX (F4NBZ, 2026-07-29). FT names the TRANSMIT VFO, so where the
+	// receive VFO is also known (FR), "split" can be derived from the two: it is
+	// on when they differ. That is a statement about the rig's actual state rather
+	// than a flag whose meaning varies by model, so FT is asked FIRST when FR
+	// answered, and ST remains the fallback for rigs without either.
+	splitProbes := []string{"ST", "FT"}
+	if y.rxVFOCmd != "" {
+		splitProbes = []string{"FT", "ST"}
+	}
+	for _, c := range splitProbes {
 		if r, err := y.ask(c + ";"); err == nil && strings.HasPrefix(r, c) {
 			answered = true
 			y.splitCmd = c