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.

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 {