fix(kenwood): record a frequency set made while transmitting

WSJT-X "Fake It" shifts the dial for the duration of each over and puts it
back afterwards, but the restore is conditional: it reads the frequency back
and only moves the dial if it disagrees with where it believes the radio
should be.

That read lands inside the window where this backend stops polling on
purpose. A Kenwood answers "?;" to IF; while it is transmitting, and treating
that as a fault used to drop the shared CAT link entirely, so the cached
state answers instead. SetFrequency wrote the command to the rig without
touching that cache — so mid-over the cache still described the pre-over
dial, WSJT-X read its own receive frequency back, concluded there was nothing
to restore, and the radio stayed on the transmit frequency. Every later over
started from there.

Reported from a session where the dial stuck at 7075500 after a full FT8
over while a bare TUNE, which never sets a frequency, worked fine.

Only simplex updates the cache. Under split, FreqHz is the transmit frequency
while the write lands on whichever VFO the operator is on, and guessing which
side moved would put a wrong number in front of the operator — a stale one
survives until the next poll.

The test reproduces the reported sequence and fails without the fix with the
same frequency the log shows.

internal/cat/kenwood.go

@@ -440,7 +440,31 @@ func (k *Kenwood) SetFrequency(hz int64) error {
 	if k.curVFO == "B" {
 		cmd = "FB"
 	}
-	return k.write(fmt.Sprintf("%s%011d;", cmd, hz))
+	if err := k.write(fmt.Sprintf("%s%011d;", cmd, hz)); err != nil {
+		return err
+	}
+	// Remember what we just commanded.
+	//
+	// While PTT is held the poll is skipped and State() hands back lastState — the
+	// rig answers "?;" to IF; mid-transmission, and reading that as a fault used
+	// to drop the whole link. But a frequency SET during that window then went
+	// unrecorded, so the cache kept describing the dial as it was before.
+	//
+	// WSJT-X's "Fake It" is exactly that sequence: move the dial, key, transmit,
+	// and afterwards put it back. Polling during the over, it was told the rig was
+	// still on the receive frequency — so there was nothing to put back, and the
+	// dial stayed on the transmit frequency for good. Every following over
+	// started from there, which is the drift that was reported.
+	//
+	// Only simplex is updated here. Under split, FreqHz means the transmit
+	// frequency while this write lands on whichever VFO the operator is on, and
+	// guessing which side moved would be worse than a stale value the next poll
+	// corrects on its own.
+	if !k.lastState.Split {
+		k.curFreq = hz
+		k.lastState.FreqHz = hz
+	}
+	return nil
 }
 
 func (k *Kenwood) SetMode(mode string) error {