feat(flex): chase a split pile-up on the skimmer's report marker

Working a DXpedition split means guessing where it listens. The useful
information is not the callsign the DX answered but the FREQUENCY that
station was calling on, and a CW skimmer already marks it: SDC posts each
decoded report to the panadapter as a spot.

Those spots reach OpsLog through the radio's spot feed. On a marker, the
TRANSMIT slice moves there plus a signed offset; the receive slice never
moves, because losing the DX is worse than missing a call. The marker
text is a setting -- it is chosen in SDC by the operator, so any constant
here would be wrong for whoever chose otherwise -- and the switch is a
button beside SPLIT, since it is turned on when a DXpedition appears and
off when it is worked.

Moves are throttled and ignore a marker landing where the slice already
is: a busy pile-up produces several reports a second and the slice would
otherwise never be anywhere long enough to call.

The spot feed is now subscribed to unconditionally. It was tied to
OpsLog's own spot overlay, so an operator running SDC with the overlay
off received nothing -- the reason no foreign spot was ever logged. The
connect-time 'spot clear' stays behind the overlay flag: it wipes every
spot on the radio, a skimmer's included.

internal/cat/cat.go

@@ -487,6 +487,8 @@ type FlexController interface {
 	// keeps freqMHz inside it, re-centring when it must. See Flex.ZoomPan.
 	ZoomPan(bandwidthMHz, freqMHz float64, centre bool) error
 	SetTXSlice(int) error // make slice idx the transmitter (tx=1)
+	// SetTXSliceFrequency moves the TRANSMIT slice only — split pile-up chasing.
+	SetTXSliceFrequency(int64) error
 	SetSplit(bool) error
 	SetNB(bool) error
 	SetNBLevel(int) error