fix(elecraft): MOX would not unkey, and the TX meters never moved

Both are the same bug. ReadState returns early while transmitting — the
rig answers '?;' to IF; then, and treating that as a fault used to drop
the link — but that early return also skipped the panel update and the
meter read.

So the panel believed the radio was still receiving. Pressing MOX again
therefore sent ANOTHER transmit command instead of RX, and the K3 stayed
keyed, exactly as reported. And the power and SWR bars were only ever
read at the one moment they mean nothing.

Reading meters while transmitting needs one more guard: a '?;' then says
when the question was asked, not what the radio supports, so the
unsupported-command memory is suspended for that read. Without it, one
badly timed refusal would silence a meter for the rest of the session.

Adds RIT/XIT offset control (±10/±100 Hz, offset shown), a 4.0 kHz filter
button for FT8, and logs the K3's icon word when it changes: there is no
command for 'is the ATU in line', the reference says the switch functions
show up as icon changes, so an operator toggling the ATU while watching
the log will name the bit and the button can then light up honestly.

internal/cat/kenwood.go

@@ -91,11 +91,18 @@ type Kenwood struct {
 	keyWPM         int // CW keyer speed, for pacing the KY buffer (see kenwood_cw.go)
 	// Commands this rig answered "?;" to — asked once, then never again.
 	unsupported map[string]bool
+	// noLatch suspends that memory while a refusal is expected to be about
+	// timing rather than capability (see ask).
+	noLatch bool
 
 	// Panel state — the K3/K4 control panel, see kenwood_panel.go. Read on the
 	// same serialised link as everything else, on a slow beat for the settings
 	// and every poll for the meters.
 	panel        KenwoodTXState
+	// The icon/status word, for working out which bit says "ATU in line" — see
+	// probeIcons. Kept so only CHANGES are logged.
+	lastIcons  string
+	iconProbes int
 	panelCycle   int
 	panelLoaded  bool
 	metersLogged int
@@ -309,6 +316,15 @@ func (k *Kenwood) ReadState() (RigState, error) {
 	if k.tx && !k.txAt.IsZero() && time.Since(k.txAt) < 30*time.Second {
 		s := k.lastState
 		s.Connected = true
+		// The panel still has to be told the radio is transmitting, and the
+		// transmit meters still have to be read — this early return used to skip
+		// both. The panel therefore showed MOX unlit while the rig was keyed, so
+		// pressing it again sent ANOTHER transmit command instead of unkeying,
+		// and the K3 stayed in TX. The power and SWR bars never moved either,
+		// for the same reason: the only moment they mean anything is the one
+		// moment they were not being read.
+		k.panel.Transmitting = true
+		k.readTXMeters()
 		return s, nil
 	}
 	raw, err := k.ask("IF;")
@@ -663,7 +679,12 @@ func (k *Kenwood) ask(cmd string) (string, error) {
 				// NOT "unsupported". Latching them off would blind the poll loop for
 				// good and read as "lost the rig". Only remember the OPTIONAL commands
 				// (FR/FT/…) so the poll loop stops paying a 600 ms timeout for those.
-				if want != "IF" && want != "ID" {
+				// While TRANSMITTING the rig refuses a great deal that it answers
+				// perfectly well on receive, so a "?;" then says nothing about what
+				// the radio supports. Latching it would silence a meter for the rest
+				// of the session on the strength of one badly timed question — and
+				// the meters are read precisely while transmitting.
+				if want != "IF" && want != "ID" && !k.noLatch {
 					k.unsupported[want] = true
 					debugLog.Printf("kenwood: this rig does not support %q — not asking again", cmd)
 				}