fix: band change from OpsLog left the frequency on the old band

The log settled it: the backend was right all along. Every set produced
"readback +1.5s FreqA=21140000 Freq=21140000 -> shown 21140000" and published
cat:state with the new frequency and band. The display did not follow.

The fault is in the frontend. Changing band does two things at once: it opens the
1.5 s freeze that protects what the operator is typing, and it commands the rig.
The rig's answer comes back in ~170 ms — inside that freeze — and the handler
DROPPED any snapshot arriving during it. The backend only emits on change, so
nothing came afterwards, and the strip kept the old frequency until the VFO was
nudged. Changing band from the radio always worked because no freeze was open.

A dropped snapshot is now kept and replayed when the freeze closes, rather than
discarded. Further typing simply defers the replay again.

frontend/src/App.tsx

@@ -594,6 +594,10 @@ export default function App() {
   // window after manual edits and skip CAT updates during it.
   const catFreezeUntilRef = useRef<number>(0);
   function noteManualEdit() { catFreezeUntilRef.current = Date.now() + 1500; }
+  // The last CAT snapshot that arrived while the freeze was open, replayed when
+  // it closes — see applyCatState.
+  const pendingCatRef = useRef<CATState | null>(null);
+  const pendingCatTimerRef = useRef<number | undefined>(undefined);
 
   // Suggested QSY frequency (Hz) for a given band + mode. Common phone /
   // CW / FT8 watering holes per IARU practice. Fallback = mid-band SSB freq.
@@ -2122,7 +2126,26 @@ export default function App() {
   function applyCatState(s: CATState) {
     setCatState(s);
     if (!s?.connected) return;
-    if (Date.now() < catFreezeUntilRef.current) return;
+    // A snapshot arriving during the freeze used to be DROPPED, and that lost the
+    // only one that mattered. Changing band from OpsLog does two things at once:
+    // it opens the 1.5 s freeze (noteManualEdit) and it commands the rig. The
+    // rig's answer comes back in ~170 ms — inside the freeze — so it was thrown
+    // away, and since the backend only emits on CHANGE, nothing followed: the
+    // frequency stayed on the old band until the operator nudged the VFO. From
+    // the radio it always worked, because no freeze was open. Confirmed on an
+    // FTDX10 (2026-07-29): the log showed the backend publishing the right
+    // frequency every time while the display did not move.
+    const now = Date.now();
+    if (now < catFreezeUntilRef.current) {
+      pendingCatRef.current = s;
+      if (pendingCatTimerRef.current) window.clearTimeout(pendingCatTimerRef.current);
+      pendingCatTimerRef.current = window.setTimeout(() => {
+        const p = pendingCatRef.current;
+        pendingCatRef.current = null;
+        if (p) applyCatState(p); // re-checks the freeze, so more typing just defers it again
+      }, catFreezeUntilRef.current - now + 50);
+      return;
+    }
     const lk = locksRef.current;
     if (!lk.freq && s.freq_hz && s.freq_hz > 0) {
       setFreqMhz((s.freq_hz / 1_000_000).toFixed(5));