Follow-up to #3771, which introduced m_meterMenuOpen as an explicit flag for the SmartMTR meter-selector's open-state. The paintEvent underline was switched to gate on it (instead of m_meterMenuRow->isVisible()), because the child widget reads isVisible()==false while the flag is hidden and rasterized into a GPU sprite — which dropped the underline from the sprite.

Two other reads of m_meterMenuRow->isVisible() for the same logical open-state remain in VfoWidget.cpp:

• VfoWidget.cpp:525 — setMeterMenuOpen(!m_meterMenuRow->isVisible()) (click-to-toggle)
• VfoWidget.cpp:2511 — if (m_meterMenuRow && m_meterMenuRow->isVisible()) setMeterMenuOpen(false); (opening a tab closes the selector)

Why this is cleanup, not a bug fix

Both are user-interaction paths that only fire on the live (visible, interactive) flag — not during sprite rasterization — so isVisible() is accurate there today and there is no current misbehavior. But now that m_meterMenuOpen is the canonical open-state, having two code paths read widget visibility for the same concept is a latent inconsistency: if either ever runs while the flag is hidden, they'd disagree with the flag the way paintEvent did.

Proposed change

Replace both reads with m_meterMenuOpen:

• line 525: setMeterMenuOpen(!m_meterMenuOpen)
• line 2511: if (m_meterMenuOpen) setMeterMenuOpen(false);

Pure consistency refactor — no behavior change expected, single file. Raised in the #3771 review.

Refs #3771, #3762.