Thanks @svabi79 — this is a thorough, well-instrumented change, and the velocity-vs-position-controller framing in the description (plus the env-tunable knobs and the AETHER_NO_DRAG_EDGEPAN A/B escape hatch) makes the UX decision easy to evaluate. CI is green across all six checks. One substantive concern and a couple of minor notes.

1. The new tune path bypasses applyTuneRequest's guards (lock / SWR sweep / diversity)

This is the main thing I'd want addressed before merge. The whole drag now routes through edgePanTuneRequested, and its MainWindow handler tunes the slice with a bare target->setFrequency(sliceFreqMhz):

queueActiveSliceForSpectrumTarget(target->sliceId());
target->setFrequency(sliceFreqMhz);

Previously the drag emitted incrementalTuneRequested → applyTuneRequest(target, mhz, IncrementalTune, …). By going around applyTuneRequest you also drop the guards it applies to every other tune source (MainWindow.cpp:5654):

• Locked slice — applyTuneRequest calls notifyTuneBlockedByLock() and restores the VFO readout. mousePressEvent starts m_draggingVfo regardless of lock state, so with this PR a user can now drag a locked slice's passband and it will retune. That's a regression in the lock affordance.
• SWR sweep — applyTuneRequest early-returns while m_swrSweep.running. The direct path lets a drag retune mid-sweep.
• Diversity mirroring — applyTuneRequest calls mirrorDiversityChildFrequency(slice, mhz); the direct path skips it, so the diversity child won't follow the parent during a drag.

I understand why you bypassed it — applyTuneRequest(IncrementalTune) ends in panFollowVfo, which is exactly the controller you're trying to keep out of the drag path. But the lock/SWR/diversity checks are orthogonal to pan-follow. Could you preserve them, e.g. by factoring the guard block (lock → notifyTuneBlockedByLock, m_swrSweep.running, mirrorDiversityChildFrequency) into a small helper that both applyTuneRequest and the edgePanTuneRequested handler call, so the edge-pan path tunes-without-follow but still honors them?

2. No upper bound on center (minor)

edgePanVelocityStep clamps the low edge (std::max(newCenter, m_bandwidthMhz/2.0)) and the MainWindow handler repeats that floor, but neither caps the high end. Holding at the right edge advances m_centerMhz (and reprojects the waterfall) unbounded until the radio echo clamps it back, which can show as overshoot-then-snap at the top of the tuning range. A symmetric upper clamp against the pan's max frequency would keep the local view consistent with what the radio will accept.

3. Direct sendCommand vs applyPanRangeRequest (nit, non-blocking)

The handler issues a raw display pan set … center=… rather than going through applyPanRangeRequest, so it doesn't update pan->applyPanStatus() locally or share that path's dedupe. You rely on the widget's local reproject for immediacy instead, which works — just flagging the divergence from the established explicit-pan path for consistency.

Nice work on the root-cause analysis and the symmetric L/R telemetry. The velocity-default sign-off is appropriately flagged as a maintainer call. Addressing #1 would be my one blocker.

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

Approving. The maintainer has signed off on the velocity feel (the UX decision this PR correctly flagged for sign-off), and I verified the engineering both by reading and by capturing live aether.perf SliceDrag telemetry on a build of this branch.

Engineering — verified correct

• Controller-fight avoidance is real. The drag path emits only edgePanTuneRequested (→ a pan-without-reveal handler using display pan set center= + setFrequency(autopan=0)); incrementalTuneRequested is removed from the drag branch and still serves wheel tuning. The two controllers can't both run during a drag.
• The tuneBlockedByGuards refactor is the right call. A naive bypass of applyTuneRequest would have silently dropped the lock + SWR-sweep affordances; extracting them into a shared guard both paths call is correct and behavior-preserving.
• Timer-stop paths are comprehensive for the normal case (tick guards on m_draggingVfo, zone-exit stops in both updateVfoDragEdgePan and edgePanVelocityStep, and mouseReleaseEvent stop + ramp reset).

Live telemetry — behaves exactly as designed

Two clean sweeps, one each direction:

• center monotonic in both (14.2836→14.3439 up; 14.3438→14.2625 down) — no jump-back
• slice parked at the zone boundary (sliceX pinned at 1780 right / 93 left) — symmetric L/R
• ramp resets on zone re-entry and climbs to cap over ~600 ms; velocity ≈ 1.0× span/s at near-full depth (≈1.2× at full), matching VMAX=120
• timer stopped cleanly on zone exit — no runaway pan observed; no errors from the feature

Recommended follow-ups (non-blocking — merging on maintainer's call)

1. Runaway-pan robustness. m_draggingVfo is cleared only in mouseReleaseEvent. If a release is ever lost mid-drag (alt-tab, mouse-grab theft, widget hide), the 30 Hz timer would keep panning + retuning the rig off the stale cursor X. Worth a belt-and-suspenders clear on hideEvent/focus-out/grab-loss (or a no-mouse-move watchdog). Didn't trigger in testing, but it now drives the radio, so the failure mode is more serious than before.
2. Asymmetric center clamp. newCenter is lower-clamped (bandwidthMhz/2) but has no upper clamp, so sweeping toward the top of the radio's range can overscroll the local view until a status update corrects it. Clamp both ends to the pan's valid range.

Both are robustness hardening, not correctness blockers. Nicely done — env-tunable feel knobs + AETHER_NO_DRAG_EDGEPAN=1 A/B hatch made validating this straightforward. 🚀