fix: the Yaesu keyer selection was thrown away when read back

Choosing "Yaesu (rig keyer)" saved correctly and still produced a WinKeyer panel
asking for a COM port. The engine is normalised on load through a chain that
names icom, flex and serial and maps EVERYTHING ELSE to "winkeyer" — so the
value came back as WinKeyer on every read, whatever the settings said.

That is why the panel offered COM3 then COM10: it genuinely believed the engine
was a WinKeyer. The list now names yaesu too.

The same shape of bug is worth watching for: a normaliser with a silent default
turns an unknown value into a plausible one instead of an error, and the symptom
appears far from the cause — here, in a panel three components away from the
setting.

frontend/src/App.tsx

@@ -2421,7 +2421,16 @@ export default function App() {
       setWkEscClears(s.esc_clears_call !== false);
       setWkSendOnType(!!s.send_on_type);
       setWkEsm(!!s.esm);
-      setWkEngine(s.engine === 'icom' ? 'icom' : s.engine === 'flex' ? 'flex' : s.engine === 'serial' ? 'serial' : 'winkeyer');
+      // Every engine has to be named here. Anything unlisted silently became
+      // "winkeyer", so choosing the Yaesu keyer in the settings still gave a
+      // WinKeyer panel asking for a COM port — the setting was saved correctly,
+      // it just never survived being read back.
+      setWkEngine(
+        s.engine === 'icom' ? 'icom'
+          : s.engine === 'flex' ? 'flex'
+            : s.engine === 'yaesu' ? 'yaesu'
+              : s.engine === 'serial' ? 'serial'
+                : 'winkeyer');
     } catch { /* keyer not configured */ }
   }, []);