feat(elecraft): a K3/K4 console — power, volume, S-meter, SWR, MOX, tune

The Elecraft backend already existed; what was missing was somewhere to
operate the radio from. This adds the panel, on the Kenwood-dialect
client the K3 already speaks, in a tab of its own beside the Yaesu and
Icom consoles.

Scope is the six controls asked for and nothing else. Every extra command
added without a radio to test it against is a control that may or may not
do what its label says, and a K3 exposes dozens.

No K3 was available while writing this, so the two halves are treated
differently. The setters are the commands the reference documents
unambiguously and whose effect is visible and reversible (PC, AG,
TX/RX). The meters are the opposite: their scaling differs by model and
firmware, so the raw answers are logged next to the power setting, the
panel says the scaling is provisional, and an unmeasured SWR shows as
'—' rather than as a perfect 1.0 — a good match on an antenna nobody
measured is the reading that costs a radio.

ATU tune sends SWT20 (the K3 front-panel tap) and logs exactly what it
sent, so a wrong mapping names itself instead of leaving an operator
guessing which button OpsLog pressed.

internal/cat/kenwood.go

@@ -92,6 +92,16 @@ type Kenwood struct {
 	// Commands this rig answered "?;" to — asked once, then never again.
 	unsupported map[string]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
+	panelCycle   int
+	panelLoaded  bool
+	metersLogged int
+	powerPeak    meterPeak
+	swrPeak      meterPeak
+
 	// rx holds bytes read but not yet consumed, ACROSS calls to ask.
 	//
 	// It has to survive: a rig answers faster than we ask, so one Read often
@@ -422,6 +432,10 @@ func (k *Kenwood) ReadState() (RigState, error) {
 		k.curRXFreq = s.RxFreqHz
 	}
 	k.lastState = s // cache for the transmit window, where we can't poll
+	// The panel rides on the same poll and the same held mutex: its own reader
+	// would have to take turns on the serial port, and the K3 is slow enough
+	// that two readers taking turns is what makes a dial lag.
+	k.readPanel(s.Mode, s.Split, s.FreqHz)
 	return s, nil
 }