Reviewed the diff against the surrounding RxApplet/VfoWidget/ThemeManager code. This is a clean, well-reasoned follow-up — nice root-cause writeup on the QSS-vs-setFont() interaction. No blocking issues found.

Correctness — the part I scrutinized hardest is fine. My first worry was that the m_freqFitPx early-return (if (px == m_freqFitPx) return;) could leave the frequency label with stale colour/family after a theme change when the fitted size happens not to move. It doesn't: ThemeManager::applyStyleSheet registers the widget and reapplyAllTrackedStyleSheets re-resolves the last-registered template on every themeChanged. Since that template keeps {{color.text.primary}} / {{font.family.freq}} as live tokens (only font-size is a literal), colour/family stay theme-reactive even on the early-return path, and applyFreqFit (wired to themeChanged) still covers a font.size.freq edit that the smart-invalidation pass would skip. So the cache is safe. 👍

Other checks, all clear:

• The fit↔reflow oscillation guard holds — the Expanding/Fixed m_freqStack gives a font-independent width, so the restyle can't feed back into a different availW. Worst case is one extra no-op applyFreqFit from the re-polish, which the px cache absorbs.
• m_filterWidthLbl removal is complete — all five RxApplet references (creation, accessibleName, the three setText sites) are gone, and the header member is dropped.
• RxApplet::formatFilterWidth is not orphaned — VfoWidget still calls it (RxApplet::formatFilterWidth(...)), so no unused-function warning.
• Dropping #include <QLabel> from FreqLabelFit.h is safe — the only two includers (RxApplet.cpp, VfoWidget.cpp) both include <QLabel> directly, so no lost-transitive-include (a class that has bitten Linux/Qt-6.4.2 CI before here).
• No null-deref / leak risks: applyFreqFit guards !m_freqLabel, heroMax guards !m_freqStack, and setFixedHeight makes height() reliable before layout.

One small, non-blocking suggestion: the safety of the m_freqFitPx early-return depends on applyStyleSheet's tracked-reapply behaviour for colour reactivity — a subtle cross-file coupling. The inline comment already notes "applyStyleSheet keeps the colour/family theme-reactive," which is enough, but a half-sentence making explicit that the colour path survives the early-return via the tracked template (not via applyFreqFit) would help the next reader avoid re-deriving it. Purely optional.

Thanks @jensenpat — the declutter rationale (band implied by the large digits, bandwidth already shown by the lit preset + passband graph) is sound, and the before/after evidence is appreciated. Nice work.

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