fix: SPLIT placed the transmitter on a stale VFO; share the meter widget

Reported on the FTDX10: listening on 14.244 with VFO B still holding 18.115 from
an earlier session, pressing SPLIT threw the transmitter onto another band. The
button only flipped the rig's split flag, and the other VFO is stale by nature —
the only transmit frequency that makes sense is one derived from where the
operator is listening NOW. SPLIT therefore places the TX VFO too: up 1 kHz on CW
and the data modes, up 5 kHz on phone, the offsets operators actually call. The
+1k / +5k buttons remain for anything else, and a test pins the mapping.

The panel also drew its own flat meters while the Flex and Icom consoles use the
shared LED-segment MeterBar. Two instrument styles in one application is just
inconsistency — it now uses the shared component, and the local one is gone.

And the three consoles are named alike: "Flex Console", "Icom Console", "Yaesu
Console", in the tabs and in the Main-view pane list, in both languages.

internal/cat/yaesu_panel.go

@@ -278,13 +278,38 @@ func (y *Yaesu) SetYaesuVOX(on bool) error {
 // other one would be silently ignored, and the operator would get a split button
 // that does nothing.
 func (y *Yaesu) SetYaesuSplit(on bool) error {
+	// Turning split ON also PLACES the transmit VFO. Flipping the flag alone
+	// transmits wherever the other VFO happens to sit — it held 18.115 from an
+	// earlier session while the operator was listening on 14.244, so pressing
+	// SPLIT threw them onto another band entirely. The other VFO is stale by
+	// nature; the only frequency that makes sense is one derived from where the
+	// operator is listening NOW.
+	//
+	// The distance is the mode's usual one: 1 kHz on CW and the data modes,
+	// 5 kHz on phone. The +1k / +5k buttons remain for anything else.
+	if on {
+		return y.SetYaesuSplitOffset(y.defaultSplitOffset())
+	}
 	y.mu.Lock()
 	cmd := y.splitCmd
 	y.mu.Unlock()
 	if cmd == "" {
 		return fmt.Errorf("yaesu: this rig answered neither ST; nor FT; — split cannot be set")
 	}
-	return y.setAndRefresh(fmt.Sprintf("%s%d;", cmd, boolDigit(on)))
+	return y.setAndRefresh(fmt.Sprintf("%s0;", cmd))
+}
+
+// defaultSplitOffset is what SPLIT means on this mode: up 1 kHz on CW and the
+// data modes, up 5 kHz on phone — the offsets operators actually call.
+func (y *Yaesu) defaultSplitOffset() int64 {
+	y.mu.Lock()
+	raw := strings.ToUpper(y.panel.RawMode)
+	y.mu.Unlock()
+	switch {
+	case strings.HasPrefix(raw, "CW"), strings.HasPrefix(raw, "RTTY"), strings.HasPrefix(raw, "DATA"):
+		return 1000
+	}
+	return 5000
 }
 
 // SetYaesuBand switches band with BS, which lands the rig on ITS OWN last-used

internal/cat/yaesu_split_test.go

@@ -0,0 +1,40 @@
+package cat
+
+import "testing"
+
+// What SPLIT means when the operator presses it.
+//
+// Flipping the rig's split flag alone transmits wherever the OTHER VFO happens
+// to sit — reported from a real FTDX10: listening on 14.244 with VFO B left on
+// 18.115 from an earlier session, pressing SPLIT threw the transmitter onto
+// another band. The other VFO is stale by nature, so the transmit frequency has
+// to be derived from where the operator is listening now.
+func TestYaesuDefaultSplitOffset(t *testing.T) {
+	cases := []struct {
+		raw  string
+		want int64
+	}{
+		// CW and the data modes work 1 kHz up.
+		{"CW-U", 1000},
+		{"CW-L", 1000},
+		{"RTTY-U", 1000},
+		{"RTTY-L", 1000},
+		{"DATA-U", 1000},
+		{"DATA-L", 1000},
+		// Phone works 5 kHz up.
+		{"USB", 5000},
+		{"LSB", 5000},
+		{"AM", 5000},
+		{"FM", 5000},
+		// Unknown or not yet read: the phone offset is the safer default — too
+		// wide is audible and obvious, too narrow lands on top of the DX.
+		{"", 5000},
+	}
+	for _, c := range cases {
+		y := &Yaesu{}
+		y.panel.RawMode = c.raw
+		if got := y.defaultSplitOffset(); got != c.want {
+			t.Errorf("mode %q → split offset %d Hz, want %d", c.raw, got, c.want)
+		}
+	}
+}