feat: record CW QSOs again

CW was excluded because SmartSDR does not route the operator's own sidetone
through DAX, so the recording sounds one-sided. The audio path is open all the
same and the other station IS captured — which is the half worth keeping.

The frontend had ONE list serving two purposes: which modes may be recorded, and
which modes the voice keyer may transmit on. Adding CW to it would have let the
DVK key the rig with speech on a CW frequency. They are now two lists: PHONE_MODES
for the keyer, RECORDABLE_MODES (phone + CW) for the recorder.

Digital modes stay out of both: their audio is a modem tone nobody will replay.

app.go

@@ -7107,14 +7107,17 @@ func (a *App) qsoRecDir() string {
 // be e-mailed later), and auto-sends it to the contacted operator when enabled
 // and an e-mail is known. Called right after a QSO is inserted (manual + UDP);
 // q must have its ID set.
-// recordableMode reports whether a QSO mode is worth an audio recording —
-// only voice (SSB/AM/FM) and CW. Digital modes (FT8/FT4/RTTY/PSK/JT…) carry no
-// useful audio, so they are never recorded.
+// recordableMode reports whether a QSO mode is worth an audio recording: voice
+// and CW. Digital modes (FT8/FT4/RTTY/PSK/JT…) carry only modem tones, which
+// nobody will ever replay, so they are never recorded.
+//
+// CW was excluded for a while because SmartSDR does not route the operator's own
+// sidetone through DAX, making the recording sound one-sided. The audio path is
+// open all the same and the other station IS captured — which is the half worth
+// keeping. Operator's call.
 func recordableMode(mode string) bool {
 	switch strings.ToUpper(strings.TrimSpace(mode)) {
-	// CW is intentionally excluded: SmartSDR doesn't route CW audio through DAX,
-	// so the recording is empty/useless. Phone modes only.
-	case "SSB", "USB", "LSB", "AM", "FM", "DV":
+	case "SSB", "USB", "LSB", "AM", "FM", "DV", "CW":
 		return true
 	}
 	return false