Per triage feedback on PR ten9876#2349, align naming with the existing
IsSpotsEnabled / IsSpotsOverrideColorsEnabled / setSpotOverrideColors
pattern:

- AppSettings key: SpotShowLines → IsSpotsLinesEnabled
- SpectrumWidget setter: setSpotLines → setSpotShowLines
- SpectrumWidget getter: spotLines() → spotShowLines()
- SpectrumWidget member: m_spotLines → m_spotShowLines
- SpotSettingsDialog member: m_spotLines → m_spotShowLines

Add a one-shot migration in MainWindow ctor to silently upgrade any
saved SpotShowLines key to IsSpotsLinesEnabled on first run.

Co-Authored-By: Claude Sonnet 4.6 <[email protected]>

- Remove the SpotShowLines → IsSpotsLinesEnabled migration block from
  MainWindow ctor: the old key was never in a released build so no real
  users can have it set, making the migration dead weight.
- Align SpotSettingsDialog tooltip with DxClusterDialog: both now say
  "Show vertical lines from the spectrum up to each spot label.\nDisable
  during contests to reduce clutter." (was truncated in legacy dialog).

Co-Authored-By: Claude Sonnet 4.6 <[email protected]>

…en9876#2385)

TciServer is a QObject child of MainWindow, so Qt deletes it during
~QWidget::deleteChildren() — which runs *after* MainWindow's value
members (including m_radioModel) have already been destroyed. This meant
stop() → releaseDaxForTci() → m_model->isConnected() dereferenced a
destroyed object on every clean exit when a radio was connected, causing
EXC_BAD_ACCESS at 0x38 on the main thread.

Primary fix: explicitly delete m_tciServer in ~MainWindow() after the
audio thread is stopped (no more daxAudioReady cross-thread signals) but
while m_radioModel is still fully alive (DAX stream-remove commands reach
the radio). TciApplet's raw back-reference is nulled first via
setTciServer(nullptr) to prevent a dangling pointer surviving in the
widget tree between the explicit delete and ~QWidget::deleteChildren().

Belt-and-braces: promote TciServer::m_model from RadioModel* to
QPointer<RadioModel>. QPointer auto-clears when the pointee is destroyed,
so the existing `if (!m_model) return;` guard in releaseDaxForTci() now
covers the post-destruct case — a future refactor cannot silently
re-introduce the crash.

…wport (ten9876#2384)

The radio encodes FFT bins as fractional pixel positions within its own
internal dBm range. Adjusting the display viewport (min_dbm/max_dbm) does
NOT cause the radio to re-encode subsequent frames with the new range.

Previously, RadioModel::handlePanadapterStatus called
PanadapterStream::setDbmRange on every min_dbm/max_dbm echo — including
viewport changes triggered by the user dragging the amplitude scale. This
caused the decode formula:

  bins[i] = maxDbm − (buf[i] / (yPix−1)) × (maxDbm − minDbm)

to use the new viewport range while the radio was still encoding with its
original range, producing a permanent dBm shift equal to the viewport
offset. Two independent reporters confirmed a ~30–40 dBm shift matching
their scale adjustment (ten9876#2384, ten9876#2310).

Fix: PanadapterStream::setDbmRange now locks the decode range to the
first value reported per stream and silently ignores subsequent calls for
that stream. The initial value comes from the radio's first status echo
(typically the −130/−40 range AetherSDR requests at pan creation, or a
profile-restored range if the pan was pre-existing). The decode range is
unlocked when the stream is unregistered, so reconnects and pan
recreations pick up the correct initial range.

The display viewport path (PanadapterModel::levelChanged →
SpectrumWidget::setDbmRange) is unchanged and continues to handle
scale/offset changes correctly.

…en9876#2380)

The exponential-backoff reconnect chain broke permanently the first time a
connection attempt failed while the network was down. The root cause was
that Qt does not emit disconnected() when a socket in ConnectingState
encounters an error — only disconnected() armed the reconnect timer, so
one failed attempt silently halted all further retries.

Three paths now all call the new scheduleReconnect() helper:

1. onDisconnected() — live connection dropped (was already working)
2. onSocketError()  — connection attempt failed before reaching Connected
3. Connect-timeout lambda — 10 s timeout while still in ConnectingState

scheduleReconnect() guards against double-scheduling with an isActive()
check (errorOccurred and the timeout can both fire for a single attempt),
and against firing after an intentional disconnect.

A per-call epoch counter (m_connectEpoch) is captured in the timeout
lambda so a stale timeout from attempt N cannot abort a later attempt N+1
that has since succeeded.

connectToCluster() now also guards against overlapping calls when the
socket is already in ConnectingState.

Affects DX cluster and RBN (both use DxClusterClient). SpotCollector and
WSJT-X (UDP) are unaffected.