Add a 'Test' button: detect the key the pedal actually emits, reconcile with config

[ericfitz]

Motivation

The app verifies the stored key (via read-back) but cannot verify the live
emitted key. On the FS17Pro these differ: a programmed key is stored immediately
but only loaded into the live keymap on a physical power-cycle (see the BLE
live-apply investigation). Result: the app can say "Programmed F16 ✓" while the
pedal still emits the old key, with no way for the user to see the mismatch.

The app DOES have the means to observe the live key — it already runs a
CGEventTap. A "Test" button can close the loop.

Proposed feature

A Test button in Settings (near the device row) that runs a guided diagnostic:

1. Prompt: "Press the foot switch now…"
2. Capture the actual keycode the pedal emits (short-lived event tap; Accessibility
   already granted). Must capture even keys not currently configured, without the
   main listener swallowing/interfering.
3. Compare the detected key to the configured trigger key for the current transport.
4. Match → "✓ Working — the pedal emits <key> as configured."
5. Mismatch (pedal emits X, configured Y) → show both options:
   • Reprogram pedal to Y — write the slot, then prompt the user to power-cycle
     the pedal, then re-Test. (Relies on the device power-cycle to apply.)
   • Use X as my trigger — update the app config's trigger key (for this
     transport) to the detected key X. Instant, no power-cycle needed — this
     path sidesteps the live-apply problem entirely by adopting what the hardware
     already emits.

(Decision: offer BOTH on mismatch — user picks reprogram-device vs. adopt-detected.)

Why it's general, not FS17Pro-specific

This helps ANY pedal/config mismatch (wrong key programmed, user unsure what the
pedal sends, etc.), so it deserves its own design rather than being bolted onto
FS17Pro support.

Design considerations / open questions

• Key capture vs. the main listener: the app's listener swallows the configured
  trigger key. The Test capture needs to see the raw press (any key) — likely pause
  the main listener during Test, or run a separate capture tap ahead of it.
• Transport awareness: "reprogram to Y" must target the connected transport's
  slot (USB vs BLE), consistent with the transport-keyed config.
• Debounce/timeout: a press window with a timeout and clear cancel.
• Localization: new strings across all 30 locales.
• Relationship to issue Detect device add/remove at runtime (USB hotplug + Bluetooth connect/disconnect) #5 (runtime device add/remove detection) — Test should
  reflect the currently-connected transport.

Deferred from the FS17Pro Bluetooth support branch (where the per-transport config,
transport-aware programming, and the "power-cycle to apply" message landed).