fix(cat-share): answer get_freq with the listening VFO, not the transmit one

Reported from a station running an IC-7850 over USB: with split engaged,
turning VFO B moved VFO A slightly. OpsLog writes nothing to that radio on
its own — but it shares it, and what it was sharing was wrong.

Hamlib's 'f' means the VFO IN USE. RigState follows ADIF, where FreqHz is
where we TRANSMIT, and the two are the same number until split is
engaged — so the adapter handed FreqHz over unchanged and every client
asking for the dial was given VFO B. A client that reads the dial and
writes it back, which is what WSJT-X and its like do, then wrote VFO B's
frequency into VFO A. Hence a shift the size of the split offset, and
hence 'it did not do this before': it only happens with split on.

get_split_freq ('i') already answers the transmit frequency and is
untouched. The one-line rule is lifted into shareRXFreq with a test that
includes this case, the simplex case, and a backend that reports split
without ever filling in the receive frequency — which would otherwise
answer a client with 0 Hz.

internal/rigctld/rigctld.go

@@ -44,7 +44,11 @@ import (
 // Rig is what the server needs from OpsLog's CAT manager. An interface, so this
 // package stays testable without a radio and without importing internal/cat.
 type Rig interface {
-	Freq() int64          // current TX frequency in Hz, 0 if unknown
+	// Freq is the frequency of the CURRENT VFO — where the operator is
+	// listening. Hamlib's "f" means the VFO in use, not the transmit one; the
+	// split TX frequency is a separate question, asked with "i". Answering "f"
+	// with the TX frequency invites a client to write it back as the dial.
+	Freq() int64          // current (RX) frequency in Hz, 0 if unknown
 	Mode() string         // ADIF mode (SSB, CW, FT8…)
 	Split() (bool, int64) // split on?, and the other VFO's frequency
 	SetFreq(hz int64) error