Nice, well-scoped feature — the hover readout is a genuinely useful addition to the TX meters, and the implementation is clean. I checked the areas most likely to bite:

Verified good

• Lifetime / RAII: m_hoverPopup = new AetherSDR::DragValuePopup(this) is parented to the HGauge, so Qt owns cleanup — no leak, and it matches the existing GuardedSlider/MeterSlider pattern. The popup's WA_TransparentForMouseEvents attribute means it won't intercept the pointer and cause an enter/leave flicker loop. All null-guarded (if (m_hoverPopup) before linger/hideNow).
• Transitive-include link fix: including DragValuePopup.h from HGauge.h means every TU that compiles an HGauge consumer needs DragValuePopup.cpp linked. I confirmed the only test target outside the main build that compiles such a TU is amp_applet_test (via AmpApplet.cpp) — and that's exactly the one you added it to. The other four consumers (TxApplet/PhoneCwApplet/TunerApplet/MeterApplet) are main-build only, which already links DragValuePopup.cpp. Coverage is complete.
• Opt-in default off keeps the telemetry gauges (PA temp/supply/fan) untouched, and mouse tracking is only enabled when the readout is.
• static_cast<HGauge*>(m_fwdGauge) is needed because TxApplet declares those members as QWidget*; the objects are constructed as HGauge, so the cast is safe.
• All six CI checks green (build + macOS/Windows/Linux + CodeQL + a11y).

One minor, non-blocking observation

• Live updates route through setValue/setValueImmediate → showHoverPopup → DragValuePopup::showValue, which calls raise() on every invocation. While a meter is hovered and actively updating during TX, that's a raise() per meter tick. It's negligible in practice (only while the pointer is parked on the bar), so no change needed — just noting it in case you ever see the badge fighting z-order with other tool windows.

Thanks for the thorough automation-bridge testing and the new hover verb — proving hover-driven UI end-to-end is a nice touch. 👍

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

Nice, clean addition — thanks @jensenpat. The hover readout reuses DragValuePopup cleanly, the feature is opt-in so the telemetry gauges (PA temp/supply/fan) stay untouched, and the hover/hover … leave bridge verb makes it genuinely provable end-to-end. A few notes, nothing blocking:

Verified good:

• No leak / no null risk. The popup is lazily created and parented to the HGauge (new DragValuePopup(this)), so it's destroyed with the gauge, and every showHoverPopup guards on m_hoverPopupEnabled + lazy-inits. linger() only arms its timer when visible, and showValue("") self-hides.
• CMake fix is complete. Adding #include "DragValuePopup.h" to the header-only HGauge means any TU that constructs an HGauge now needs DragValuePopup.cpp at link. I checked every test target: amp_applet_test is the only test that pulls in an HGauge-bearing source, and it's exactly the one you added the source to. The main AetherSDR target already lists DragValuePopup.cpp. So nothing else link-breaks.
• doHover boundary handling covers widget-not-found and not-visible, and the synthetic QEnterEvent + no-button QMouseMove faithfully mirrors a real hover (mouse tracking is enabled by setHoverValuePopupEnabled). std::lround in TxApplet.cpp is backed by an explicit <cmath>.

Minor, optional:

• While hovered, setValue/setValueImmediate call showHoverPopup → showValue → move() + raise() on every meter tick. On a live TX meter that's ~10–20 Hz of re-raising a top-level tooltip window. It's harmless functionally (WA_ShowWithoutActivating keeps focus out of it), but you could cheaply gate the re-show on the formatted text actually changing (cache the last string) to avoid the churn. Not required for merge.

Looks good to me overall.

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

Reviewed with an 8-angle finder + verify pass (correctness, removed-behavior, cross-file, reuse/simplification, efficiency, altitude, conventions, and per-meter value/unit accuracy). Clean, careful PR — the hide/reparent/re-enter edge cases are handled explicitly and the ### hover bridge verb is properly documented.

The scary-sounding candidates all refuted on inspection:

• No DragValuePopup leak — it's QWidget(parent, Qt::ToolTip|…); the ToolTip flag only changes window management, the QObject parent is retained, so it's destroyed with the HGauge.
• Disable/re-enable re-show works — the isVisible() gate in showHoverPopup is exactly what re-shows the popup after hideNow().
• Overridden mouse/enter/leave/hide handlers all call the base and early-return when !m_hoverPopupEnabled — inert for gauges that don't opt in.

Non-blocking polish (optional, can be follow-ups):

1. The readout shows m_value (the true set value) while the bar renders the ballistics-smoothed m_smooth — defensible (exact number > lagging bar), just means badge/bar disagree briefly during a fast swing.
2. SWR formatter has no NaN/inf guard — an upstream inf (forward=0) would print "inf:1"; a cheap isfinite/qBound guard would harden it.
3. SWR can show a stale ratio at 0 W, but that's pre-existing updateMeters behavior (the bar already shows it) — out of scope here.

Approving.