…aethersdr#2931)

## Summary

With two or more slices, TX would not stay on the slice the user picked
— it kept jumping back to another slice every couple of seconds, and the
user couldn't keep TX where they wanted it. Root cause is
`cmdSetSplitVfo` reclaiming TX on every `set_split_vfo 0` **poll**
rather than on a real split-state change.

## Root Cause

Each rigctld / PTY CAT channel is bound to a fixed slice
(`m_sliceIndex`). `cmdSetSplitVfo` moved TX onto that slice whenever a
client sent `set_split_vfo 0` (split disabled). aethersdr#2568 added an
`!isTxSlice()` guard to stop the redundant **command spam**, but that
only suppressed the already-TX case — it didn't stop TX from being
**seized**.

Hamlib loggers (VARA, VARAC, N1MM, fldigi) poll `set_split_vfo 0 VFOA`
every few seconds. With a CAT channel bound to a non-TX slice the
sequence was:

```
user clicks slice A TX badge    → slice set 0 tx=1   (A is TX)
~1.7 s later logger polls split → channel bound to slice B
cmdSetSplitVfo sees B != TX      → slice set 1 tx=1
TX jumps back to B
```

The `!isTxSlice()` guard actually *guaranteed* the re-seize: the user
moving TX away is exactly the moment the bound slice becomes non-TX,
which re-satisfies the guard on the very next poll.

Captured in the connection log (slice 0 = A, slice 1 = B, single client,
no split):

```
08:11:59.663  TX: C162|slice set 0 tx=1     ← user clicks A's TX badge
08:11:59.785  RX: slice 0 ... tx=1          ← A is TX (user succeeded)
08:12:01.379  TX: C167|slice set 1 tx=1     ← logger split poll, 1.7 s later
08:12:01.379  TX: C168|slice set 1 tx=1
08:12:01.379  TX: C169|slice set 1 tx=1
08:12:01.379  TX: C170|slice set 1 tx=1
08:12:01.498  RX: slice 1 ... tx=1          ← TX yanked back to B
```

## Fix

Track the last split state per `RigctlProtocol` instance (tri-state:
unknown / disabled / enabled) and reclaim TX only on a genuine
split→non-split **transition** (1→0 edge) — never on a steady-state poll
or the first report after connect.

```cpp
const bool wasEnabled  = (m_lastSplitEnable == 1);
const bool firstReport = (m_lastSplitEnable < 0);
m_lastSplitEnable = enable ? 1 : 0;

if (!enable && wasEnabled && !firstReport) {
    if (auto* s = currentSlice(); s && !s->isTxSlice())
        s->setTxSlice(true);
}
```

A logger that sits in non-split and polls repeatedly no longer fights
the user's TX choice, while a real "turn split off" still moves TX back
to the client's slice.

## Test plan

- [x] macOS, FLEX-6600 fw 4.2.18, VARAC on rigctld
- [x] Slice A = TX, add slice B → select TX back to A → TX **stays** on
A (previously yanked to B within ~2 s)
- [x] Genuine split toggle (split on → split off) still moves TX to the
channel's slice
- [ ] Reviewer: confirm contest-logger split workflows (N1MM true split
on/off) still behave on Windows/Linux

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-authored-by: Jeremy Fielder <kk7gwy@aethersdr.com>