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.

app.go

@@ -16230,6 +16230,14 @@ func (a *App) reloadCAT() {
 		go a.startQSORecorderIfEnabled()
 	}
 	a.reloadCATShare(s)
+	// Preferences that the LINK does not depend on, pushed to the rig that is
+	// already connected. They are deliberately absent from catLinkSig — none of
+	// them is worth dropping the CAT link (and with it WSJT-X's rigctl session)
+	// to apply — so without this they waited for the next launch, and the
+	// operator ticking "RTTY on USB" watched the rig go on choosing LSB.
+	if s.Enabled && s.Backend == "yaesu" && a.cat != nil {
+		_ = a.cat.YaesuDo(func(y cat.YaesuController) error { y.SetRTTYUpper(s.YaesuRTTYUSB); return nil })
+	}
 	// Nothing about the link changed → leave it connected. See catLinkSig.
 	if sig := catLinkSig(s); sig == a.catSig {
 		applog.Printf("cat: settings saved, link unchanged — staying connected")