fix(chase-new): the toolbar button was read once, too early

An operator waited over a minute and the button never appeared; opening
Settings and pressing Cancel made it appear at once. That is the whole
diagnosis — Cancel was the only thing that re-read the option.

GetChaseNew returned the cached atomic, which exists for the MQTT goroutine
and is false until startup has read the setting. The UI asked while the
database was still opening, was told "off", believed it, and never asked
again. It now reads the setting, like the grid-chasing binding beside it.

The frontend asks again at the two moments this class of race resolves: when
GetStartupStatus returns, and when the first logbook load succeeds — the seam
that already re-reads the connection label for exactly this reason, with a
comment saying so.

The open/closed state was already remembered per machine; it is now in
PORTABLE_KEYS with the other widget toggles, so it travels with data/ like the
rotor and amplifier panels rather than being the one that does not.

frontend/src/App.tsx

@@ -2648,6 +2648,9 @@ export default function App() {
         // case its one-shot fetch ran during the startup race (before the
         // backend was determined) and grabbed the wrong/stale value.
         GetDBConnectionInfo().then((i) => { if (alive) setDbConn(i as any); }).catch(() => {});
+        // Same race, same fix: the toolbar options were read once at mount,
+        // possibly before the profile was active, and a "no" then was final.
+        refreshChaseNew();
       } else if (!ok && alive && tries++ < 360) {
         // Quick retries at first (normal startup connects in ~2 s); then keep
         // trying for several minutes, because the very first migration against a
@@ -2660,7 +2663,7 @@ export default function App() {
     };
     attempt();
     return () => { alive = false; if (timer) window.clearTimeout(timer); };
-  }, [refresh]);
+  }, [refresh, refreshChaseNew]);
   useEffect(() => {
     (async () => {
       try {
@@ -2681,6 +2684,10 @@ export default function App() {
       loadStation();
       loadLists();
       loadCATCfg();
+      // Options the toolbar reads. At mount the database may still be opening,
+      // and a one-shot read then answers "off" for everything — which is why the
+      // Chase New button only appeared after a trip through Settings.
+      refreshChaseNew();
     })();
     // Poll the CAT state at launch until the rig reports a frequency: the
     // backend connects asynchronously and only PUSHES cat:state on change, so

frontend/src/lib/uiPref.ts

@@ -17,6 +17,7 @@ const PORTABLE_KEYS = [
   'opslog.autofocusWB',   // auto-focus Worked-before
   'hamlog.filterPresets', // Filter Builder saved presets
   'opslog.showRotor',     // rotor compass shown next to the keyers
+  'opslog.showChaseNew',  // Chase New panel shown next to the keyers
   'opslog.showAmpWidget', // amplifier widget shown next to the keyers
   'opslog.ampSel.widget', // which amplifier that widget shows ("all" or an amp id)
   'opslog.showBeamOnMap', // antenna beam lobe drawn on the Main map

pskchase.go

@@ -263,7 +263,13 @@ func (a *App) GetChaseNewSpots() []ChaseNewSpot {
 }
 
 // GetChaseNew reports whether the widget is on.
-func (a *App) GetChaseNew() bool { return a.chaseNewEnabled() }
+//
+// Reads the SETTING, not the cached atomic. The atomic exists for the MQTT
+// goroutine and is false until startup has read the option — so a UI that asked
+// this while the database was still opening was told "off", believed it, and
+// never asked again. The toolbar button only appeared after opening Settings
+// and closing it, which is what re-read it.
+func (a *App) GetChaseNew() bool { return a.settingOr(keyChaseNew, "") == "1" }
 
 // SetChaseNew turns the widget on or off and brings the feed up or down with it.
 func (a *App) SetChaseNew(on bool) error {