Preflight

• I have read GOVERNANCE.md and confirmed this change requires an RFC
• I have searched existing issues and this RFC has not been proposed before
• I have not opened a PR for this change yet

Problem

The current slice S-meter (on the slice box) shows the present signal level but lacks two things that aid real-world operating:

1. No extremes markers — there's no visual record of recent peak and minimum levels, so it's hard to judge how a fluctuating signal is behaving without staring at the meter continuously. This matters when comparing antennas, monitoring fading/QSB, or assessing a station's signal stability.
2. Limited indicator dynamics — the indicator movement doesn't convey signal motion as clearly as it could.

Proposal

Redesign the slice-box S-meter to add:

1. Optional extremes markers — peak-hold and minimum-hold markers that retain the recent maximum and minimum levels, with a configurable hold/decay. Off by default so the meter stays clean for users who don't want them; opt-in via a setting.
2. Improved indicator dynamics — smoother, more legible indicator response that better reflects signal motion, conceptually similar to SmartMTR's metering but laid out to fit AetherSDR's slice box rather than copying SmartMTR.

The aim is SmartMTR-comparable readability and behavior, with a layout designed for AetherSDR's existing slice-box layout.

Cross-platform impact

1. The change is in shared GUI/model code (slice meter widget + its data source), with no platform-specific code — identical behavior and appearance on Linux, macOS, and Windows.
2. Respects existing theme tokens — no new colors or fonts introduced.
3. Meter data continues to come from the existing meter pipeline; no protocol or threading changes, and rendering stays on the current path.

Alternatives considered

Alternatives considered?
Leave as it is — simplest, but doesn't address peak/minimum visibility or the readability of signal motion that the Problem describes.

Why this approach?
It delivers SmartMTR-comparable readability where operators expect it (the slice meter) while staying opt-in and theme-consistent, so existing users see no change by default and nothing platform-specific or protocol-related is touched.

Implementation scope

src/gui/VfoWidget.cpp
Also I prefer creating a separate file for the meter visualization - just to separate its logic.