… stop the unconditional macOS Input Monitoring prompt (#3257). Principle III.

`MainWindow` started `UlanziDialBackend` and `HidEncoderManager` on every launch.
The Ulanzi macOS backend calls `IOHIDManagerOpen(..., kIOHIDOptionsTypeSeizeDevice)`
and HIDAPI's macOS backend opens with the same flag internally — both trip the
TCC Input Monitoring prompt on first launch even on machines with no supported
hardware. Existing reproduction: K5PTB's screenshot of AetherSDR appearing in
System Settings → Privacy & Security → Input Monitoring with no peripheral
ever connected.

Fix:
- New `UlanziDialEnabled` / `HidEncoderEnabled` AppSettings keys, default
  "False". `MainWindow` ctor gates the `start()` / `loadSettings()` calls
  on them.
- New "USB Control Surfaces" group at the top of the Serial tab in
  `RadioSetupDialog`, with one checkbox per backend. Flipping a checkbox
  on emits `serialSettingsChanged()`, which `MainWindow::
  wireRadioSetupDialogSignals` now handles by kicking `start()` /
  `loadSettings()` — so the TCC prompt fires the moment the user
  affirmatively asks for the feature, with context, instead of on every
  launch.
- `wireRadioSetupDialogSignals` `connect()` moved out of the
  `#ifdef HAVE_SERIALPORT` wrap so the Ulanzi/HID branch runs even in
  builds without serial-port support (the dial/encoder backends exist
  regardless).
- `NSInputMonitoringUsageDescription` added to `packaging/macos/
  Info.plist.in` so the prompt — when it does fire — carries an app-
  supplied rationale explaining it is only for optional USB control
  surfaces.

`start()` and `loadSettings()` are idempotent (each guards re-open), so
re-firing on unrelated settings changes is harmless.

Principle III is the load-bearing citation: the new user-facing labels
("Enable Ulanzi Dial", "Enable HID encoders / StreamDeck+ (RC-28,
PowerMate, ShuttleXpress, …)") match the visible peripheral names users
recognize, and the Info.plist rationale points to "Preferences → Serial"
— the exact tab name registered in `RadioSetupDialog.cpp:472`.

Blast radius: HidEncoderManager::loadSettings risk_score=0.306, 3 high-risk
affected (top: MainWindow::MainWindow, AppSettings::instance,
AppSettings::value); RadioSetupDialog edit risk_score=0.183, 3 high-risk
affected (top: MainWindow::MainWindow, MainWindow::wirePanadapter,
MainWindow::buildMenuBar). All callers are structural bridges to MainWindow's
ctor and the AppSettings singleton; edits are purely additive (new if-gate,
new connect branch, new QGroupBox), no symbol contracts change.

Verification:
- `cmake` is not installed on this host so no local build was possible —
  relying on CI for compile + link.
- No cross-TU symbol motion, no new project-header includes, no
  Q_LOGGING_CATEGORY changes — test-target link audit not applicable.
- Manual UX path to verify post-merge: fresh macOS install, build,
  launch — confirm no Input Monitoring prompt; open Radio Setup →
  Serial, tick "Enable Ulanzi Dial" — confirm prompt fires now with
  rationale text.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

Without this, the new HidEncoderEnabled=False default in this PR
silently turns off existing users' working HID encoders (RC-28,
PowerMate, ShuttleXpress, StreamDeck+) until they discover the
Radio Setup → Serial checkbox.  Linux + Windows hidraw paths have
no TCC concern, so honouring the prior intent on first launch is
the right default for them.

Mechanism: at MainWindow ctor, if HidEncoderEnabled isn't set at
all (first launch after upgrade), copy HidEncoderAutoDetect's
value into it.  Subsequent toggles in the dialog own the key.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>