Thanks for this @svabi79 — clear root-cause writeup, and the fix is well-architected. I traced the diff against the surrounding code on main; it holds up.

What works well

• Single source of truth for the recenter. Extracting recenterPanFollowOnSlice0() and self-guarding it on m_panFollowActive (and m_sliceDragInProgress, and the existing WFM precedence) means all three call sites — enable, slice-0 frequencyChanged, and drag-end — go through one guarded path. That's cleaner than the captured centerPan lambda it replaces, and refetching slice(0) fresh each call rather than capturing s by value is the right move.
• Drag-end signalling is sound. m_draggingVfo is set true at both drag-start sites (in-window passband + slice-flag hit) and is only ever cleared in mouseReleaseEvent (line 6361). The earlier early-returns in that handler are all mutually-exclusive drag states (TNF / divider / dBm / time-scale / bandwidth), so the VFO release always reaches the new emit sliceDragActiveChanged(false). No double-emit, no missed end.
• Mirrors the documented WFM precedence, and the UX call (slice follows cursor during drag, snaps to center on release) is reasonable and flagged for maintainer sign-off — consistent with the existing convention.
• CI is green across build / check-windows / check-macos / analyze(cpp) / CodeQL.

One edge case worth a note (non-blocking)

The defensive m_sliceDragInProgress = false in setPanFollow() covers drag-abandoned-then-Pan-Lock-toggled. But if a VFO drag is ever torn down without a mouseReleaseEvent and without a subsequent Pan Lock toggle — e.g. the pane is removed mid-drag, or the mouse grab is lost — m_sliceDragInProgress sticks true and Pan Lock stays silently suppressed until the next toggle. In practice Qt delivers the release to the grabbing widget so this is narrow, and there's no leaveEvent/hideEvent path that resets m_draggingVfo today, so it's unlikely to trigger. Just flagging it; if you wanted belt-and-suspenders, clearing the flag wherever a drag could be cancelled would close it, but I don't think it blocks merge.

Minor observation (not a bug): sliceDragActiveChanged fires from every panadapter's SpectrumWidget into the single shared m_sliceDragInProgress, so dragging a slice on a non-Slice-A pane also stands Pan Lock down for that drag. It's a harmless no-op — recenter only triggers on slice-0 frequencyChanged, which a different slice's drag won't emit, and the release-time recenter is qFuzzyCompare-guarded.

Nicely measured and scoped. 👍

_{🤖 aethersdr-agent · cost: $3.9199 · model: claude-opus-4-8}

I reviewed this against the current merge ref and I do not see a merge blocker.

The change is nicely scoped: SpectrumWidget now reports the full VFO drag lifetime, and MainWindow centralizes Pan Lock recentering through recenterPanFollowOnSlice0(), guarded by Pan Lock state, drag state, and the existing WFM precedence. That fixes the root conflict cleanly: during drag, the drag controller owns pan movement; on release, Pan Lock gets one chance to reassert.

Validation:

• Built the PR merge ref successfully with cmake --build build --target AetherSDR --parallel 8
• Ran the automation bridge smoke checks: ping, dumpTree, Pan Lock invoke, and tools/automation_validate.py
• Confirmed automation stayed non-transmitting
• Ran git diff --check
• Ran python3 tools/check_a11y.py; only existing repo-wide warnings, none in the touched files
• Manually tested the slice-drag/Pan Lock behavior and it worked correctly

The remaining abandoned-drag edge case already noted looks narrow and non-blocking. From my review and manual test, this looks ready to merge once maintainer approval is satisfied.

Approved. Reviewed the diff and tested live on a FLEX-8600: with Pan Lock on, dragging Slice A now stands down the per-tick recenter for the whole drag (no more ~0.33 MHz pan lurching/jumping) and recenters once on release so Pan Lock re-asserts.

• Clean refactor: the inline centerPan lambda becomes recenterPanFollowOnSlice0(), called on enable, on slice-0 frequency change, and once on drag-end.
• Drag state is driven by a new SpectrumWidget::sliceDragActiveChanged(bool) emitted on VFO-drag start (marker + filter-passband paths) and release; m_sliceDragInProgress suppresses recentering during the drag.
• setPanFollow() resets m_sliceDragInProgress defensively (covers a drag abandoned without a mouse-release).
• WFM precedence preserved (WFM-held pan still wins; Pan Follow stands down).

Not a keying path (Principle VI N/A). CI green on all 6. Thanks @svabi79 — nice fix for a real annoyance.