Context

PR #2925 changed `FlexWheelMode::Volume` to call `applyMasterVolume()`
instead of `SliceModel::setAudioGain()`, fulfilling the #2921 user
request to match SmartSDR's wheel-volume-is-master-volume behavior.

But PR #2888 (AetherControl) had previously added a separate
`FlexWheelMode::MasterAf` mode that already routed to master volume —
intended as a new "master volume" wheel mode while leaving the existing
"Volume" as slice gain.

After #2925 lands, both modes are behaviorally identical:

```cpp
// src/gui/MainWindow.cpp, applyFlexControlWheelAction():
} else if (actionId == "WheelVolume") {
// ... adjust master volume ...
} else if (actionId == "WheelMasterAf") {
// ... adjust master volume (same code) ...
}
```

Two action strings, two enum values, identical behavior.

Why this is a wart

• The FlexControl + AetherControl wheel-mode selectors expose both
  "Volume" and "MasterAf" as separate choices. Users picking either get
  the same outcome — confusing.
• The shortcut-actions list in `RadioSetupDialog.cpp` (`WheelVolume`,
  `WheelMasterAf`) is the same redundancy.
• Anyone reading the code has to verify "these two do the same thing"
  rather than getting the answer from the mode name alone.

Recommended resolution

Remove `FlexWheelMode::MasterAf` and its action string
`WheelMasterAf`. Reasoning:

• `WheelVolume` is the more familiar name (SmartSDR uses it, the
  pre-Add AetherControl virtual FlexControl controller #2888 codebase used it)
• It's the mode the user from flex control volume wheel control master volume instead of slice volume #2921 was asking about
• MasterAf was a parallel addition in Add AetherControl virtual FlexControl controller #2888 that became redundant
  once [controllers] Route FlexControl volume to master volume #2925 redefined Volume's meaning
• Removing it has minimal user impact since both modes do the same
  thing — anyone bound to `WheelMasterAf` can rebind to `WheelVolume`
  with no behavior change

If we want to preserve the per-slice gain control that `WheelVolume`
previously offered, add a new `WheelSliceGain` mode rather than
trying to repurpose either of the two existing master-volume modes.

Touch points

Migration consideration

A user who bound an Aux button to `WheelMasterAf` in the v26.5.3-with-#2888 release would lose that binding after this consolidation. Options:

1. Migration on AppSettings load — translate any stored `WheelMasterAf`
   to `WheelVolume` once on first launch. ~5 lines, no user-visible loss.
2. Just drop it, no migration — bindings to `WheelMasterAf` silently
   fail to bind. Documented in changelog.

Recommend option 1 if anyone has had time to bind in the brief window
between #2888 (today) and this consolidation.

Effort

~1 hour with migration; ~30 min without.

References

• flex control volume wheel control master volume instead of slice volume #2921 — original SmartSDR-parity request
• [controllers] Route FlexControl volume to master volume #2925 — Volume→master volume change (this PR)
• Add AetherControl virtual FlexControl controller #2888 — original MasterAf addition