Looks good — the fix is well-targeted and the rationale lines up with the documented recenter policy.

What I verified:

• RadioModel::addSliceOnPan(panId, freqMhz) exists at src/models/RadioModel.cpp:1441 and is the canonical "create slice at a specific frequency on a specific pan" entry point — matches the call pattern already used elsewhere in MainWindow.cpp:12257.
• It emits sliceCreateFailed on radio rejection, so the comment about honoring the max-slices limit is accurate.
• The nullptr sentinel for "empty pan, caller decides" is preferable to returning the wrong-pan active slice, which was the root cause of #3086.
• The click-spawn / wheel-no-op asymmetry matches SmartSDR behavior as called out in the doc update — a stray scroll over an empty pan shouldn't conjure a slice.

Minor note (non-blocking): in the click handler's empty-pan branch, resolveClickedPanId() gets called twice (once inside resolveSpectrumTuneTarget, once after it returns null). Iterating m_panStack->allApplets() twice is harmless given the small number of pans, but you could thread the resolved panId through if you wanted to avoid it. Not worth a respin.

Thanks for keeping the legacy "pan not in stack" fallback to activeSlice() intact — that path is the truly-unknown-pan case and is distinct from the empty-pan case the fix targets.

_{🤖 aethersdr-agent · cost: $3.4830 · model: claude-opus-4-7}