## Summary

Implements #2984. Wires `MainWindow::onSliceAdded()` to the new
`SliceModel::lockedFeedbackActiveChanged` signal (from #2983 / #3017) so
a 3-second status-bar message fires on the first blocked tune of a
sustained sequence:

> Slice is locked — unlock to tune.

## Why this is the option-2 path

The issue listed two approaches: per-path latches in `nudgeFreq` /
`rx.tuneKnob` / HID coalesce, or driving the message off a single
SliceModel signal. With #2983 landed, the signal route is one
connection, automatic dedup (only fires on the false→true edge), and
naturally covers every current and future blocked-tune entry point — no
per-call-site latch state.

## Dedup behavior

`lockedFeedbackActiveChanged(true)` fires once when the LOCKED feedback
gate goes active. The 500 ms timer in SliceModel keeps the gate active
across rapid repeated blocked attempts (stuck MIDI knob, held arrow
key), so a burst gives **one toast at the start**, not one per event.
When the timer expires without another block, the gate clears; the next
blocked attempt re-triggers a fresh toast.

## Scope

- 1 file, +10 / -0
- No new state in MainWindow
- Same message for keyboard / MIDI / HID / wheel / direct-entry /
band-shortcut paths — operator knows which input they used; the message
just surfaces the lock cause
- Matches the existing memory-recall lock toast pattern in
MainWindow.cpp

## Test plan

- [x] Clean build, 0 warnings
- [ ] Manual: lock slice, scroll-wheel tune ⇒ LOCKED overlay shows AND
status-bar toast appears
- [ ] Manual: lock slice, hold keyboard right-arrow for 2s ⇒ overlay
shows continuously, ONE toast at start (not spammed)
- [ ] Manual: lock slice, spin MIDI tune knob ⇒ same as above
- [ ] Manual: unlock slice, scroll-tune ⇒ no toast (gate didn't
activate)

Closes #2984.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

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

…ethersdr#3017)

## Summary

Implements aethersdr#2983. Moves the 500ms LOCKED visual-feedback gate from
per-widget timers in `VfoWidget` and `RxApplet` to a single `QTimer` in
`SliceModel`.

Before: each widget had its own `m_lockedFrequencyTimer` +
`m_showingLockedFrequencyFeedback` bool. Two timers, two state mirrors,
same UX concept.

After: one timer + one bool on `SliceModel`. New signal
`lockedFeedbackActiveChanged(bool)` drives repaint; the existing
`tuneBlockedByLock()` keeps its one-shot semantics for per-event side
effects (cancel direct-entry, future status-bar ack — see aethersdr#2984).
`setLocked(false)` and `applyStatus("lock=0")` both clear feedback
centrally.

## Why this is worth doing

- One state variable for "is feedback active" — no risk of widgets
drifting out of sync.
- Future consumers (spectrum-widget VFO marker, hardware controller LED,
status bar) connect to one signal, not two.
- Simpler clean-up: `setSlice()` no longer needs to manually clear
per-widget state when swapping slices.

## Stats

- 6 files changed, **+73 / -83**
- Drops 2 `QTimer` members + 2 mirrored `bool` flags + 2 `static
constexpr` 500ms constants across the widget pair.
- Adds 1 `QTimer` + 1 `bool` + 1 `kLockedFeedbackMs` on `SliceModel`.

## Test plan

- [x] Clean build (680 targets, 0 warnings)
- [x] Full test suite passes (18/18)
- [ ] Manual: lock slice via RX applet ⇒ scroll-wheel tune ⇒ both VFO
and RX freq label show "LOCKED" together for 500ms, then both clear.
- [ ] Manual: lock slice ⇒ keyboard/MIDI tune ⇒ same as above.
- [ ] Manual: lock slice ⇒ blocked tune ⇒ unlock immediately ⇒ overlay
clears immediately (doesn't sit for the remainder of 500ms).
- [ ] Manual: VFO direct-entry open ⇒ blocked tune attempt ⇒
direct-entry cancels, LOCKED shows.

Closes aethersdr#2983.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

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

…dr#3020)

## Summary

Implements aethersdr#2984. Wires `MainWindow::onSliceAdded()` to the new
`SliceModel::lockedFeedbackActiveChanged` signal (from aethersdr#2983 / aethersdr#3017) so
a 3-second status-bar message fires on the first blocked tune of a
sustained sequence:

> Slice is locked — unlock to tune.

## Why this is the option-2 path

The issue listed two approaches: per-path latches in `nudgeFreq` /
`rx.tuneKnob` / HID coalesce, or driving the message off a single
SliceModel signal. With aethersdr#2983 landed, the signal route is one
connection, automatic dedup (only fires on the false→true edge), and
naturally covers every current and future blocked-tune entry point — no
per-call-site latch state.

## Dedup behavior

`lockedFeedbackActiveChanged(true)` fires once when the LOCKED feedback
gate goes active. The 500 ms timer in SliceModel keeps the gate active
across rapid repeated blocked attempts (stuck MIDI knob, held arrow
key), so a burst gives **one toast at the start**, not one per event.
When the timer expires without another block, the gate clears; the next
blocked attempt re-triggers a fresh toast.

## Scope

- 1 file, +10 / -0
- No new state in MainWindow
- Same message for keyboard / MIDI / HID / wheel / direct-entry /
band-shortcut paths — operator knows which input they used; the message
just surfaces the lock cause
- Matches the existing memory-recall lock toast pattern in
MainWindow.cpp

## Test plan

- [x] Clean build, 0 warnings
- [ ] Manual: lock slice, scroll-wheel tune ⇒ LOCKED overlay shows AND
status-bar toast appears
- [ ] Manual: lock slice, hold keyboard right-arrow for 2s ⇒ overlay
shows continuously, ONE toast at start (not spammed)
- [ ] Manual: lock slice, spin MIDI tune knob ⇒ same as above
- [ ] Manual: unlock slice, scroll-tune ⇒ no toast (gate didn't
activate)

Closes aethersdr#2984.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

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