fix(yaesu): the RTTY sideband reaches the rig that is already connected

Ticking "RTTY on USB" changed nothing: the flag is deliberately absent
from catLinkSig — none of these preferences is worth dropping the CAT
link, and with it WSJT-X's rigctl session, to apply — so saving the
settings left the link alone and the running client kept its old answer
until the next launch.

Preferences that the link does not depend on are now pushed to the
connected rig when the settings are saved, through the Yaesu escape on
the manager. SetRTTYUpper joins the controller interface for that: it is
a preference rather than a command, but it has to be reachable on a rig
that is already talking.

internal/cat/yaesu_panel.go

@@ -84,6 +84,11 @@ type YaesuTXState struct {
 // same shape as FlexController and IcomController.
 type YaesuController interface {
 	YaesuState() YaesuTXState
+	// SetRTTYUpper is a preference, not a command — see Yaesu.SetRTTYUpper. It
+	// belongs here so a change of mind reaches the RUNNING rig: the link is not
+	// rebuilt for it, and until it was reachable this way the setting only took
+	// effect on the next launch.
+	SetRTTYUpper(bool)
 	RefreshYaesu() error
 	SetYaesuPower(int) error
 	SetYaesuMicGain(int) error

internal/cat/yaesu_test.go

@@ -425,3 +425,19 @@ func TestYaesuRTTYSideband(t *testing.T) {
 		t.Errorf("CW = %q, want CW-U", got)
 	}
 }
+
+// The RTTY sideband is a preference the LINK does not depend on, so it is not
+// in catLinkSig and the link is not rebuilt for it — which means the running
+// client has to accept it. It did not, and the setting waited for the next
+// launch while the rig went on choosing LSB.
+func TestYaesuAcceptsTheRTTYSidebandWhileConnected(t *testing.T) {
+	var y YaesuController = &Yaesu{}
+	y.SetRTTYUpper(true)
+	if got := y.(*Yaesu).rttyUpper; !got {
+		t.Error("a running Yaesu ignored the RTTY sideband")
+	}
+	y.SetRTTYUpper(false)
+	if got := y.(*Yaesu).rttyUpper; got {
+		t.Error("it could not be turned back")
+	}
+}