feat(keyer): split Keyer and Straight Key pages, allow both interfaces at once

[tcpreplay-dev]

Stacked on #4. Separated deliberately from the keying work so this UI direction can be
rejected without losing it.

Why

One HaliKey device served both roles, with a global "straight key mode" flag deciding which.
An operator owning both a paddle and a straight key had to reconfigure to switch. Role is now
determined by the device an edge arrives on, so both can be connected at once.

Options dialog

"HaliKey" → "Keyer", with a new Straight Key page after it. Keyers are the common
case, so that page stays first.

Keyer page gains a Radio Keyer section for KP only — KS, CW, SD and ML already
have main-window controls and stay out of it:

• Iambic A/B, paddle orientation
• Keying weight as a slider with exactly the 8 values KP accepts (090–125 in fives),
  shown as a 0.90–1.25 ratio rather than the raw integer

KP carries all three fields in one command, so changing any one re-sends the other two, and
the page follows the radio's echo rather than assuming its writes landed. The local paddle
swap sits in its own group because it composes on top of the radio's orientation rather
than replacing it — two controls that otherwise look like they do the same thing.

Straight Key page carries the timing buffer from #4: an on/off switch, speed bounds, and
dah/dit ratio, with the resulting delay shown live in ms. The operator states how they send;
the buffer arithmetic stays out of the UI.

Connection controls are one shared widget, so the two pages can't drift and the port-conflict
rule has a single home.

Auto-connect replaces Refresh

A gated poll drives both reconnect-on-hotplug and list freshness, leaving the button nothing
to do. Two details that matter: the list rebuilds only when the port set actually changes
(otherwise an open popup or a live selection gets yanked away), and polling is gated rather
than always-on, since Windows enumeration is materially more expensive than macOS IOKit.

Port conflict is enforced in software

The platforms disagree. Windows opens exclusively and fails the second attempt; macOS and
Linux both succeed silently, leaving two readers on one key. So the guard can't rely on the
OS.

Comparison is by port string, so on macOS one interface appearing as both cu.* and tty.*
isn't caught — stated in the page's help text rather than papered over.

Settings migration

Keys move to per-role groups (keyer/*, straightkey/*), migrating the old halikey/*
values into whichever role the retired straightKeyMode flag selected, so existing setups
survive the upgrade.

Defaults: iambic B, weight 1.10, slowest 20 WPM, dah/dit 4.0 → 390 ms pre-roll.

Also removes HalikeyDevice::availablePorts() and the halikeyEnabled setting, both of
which had no callers.

Known inconsistency

buttonrowdispatcher.cpp:181 still falls back to iambic A when KP is unreported, where
this page falls back to B. The window is only until the RDY dump lands, but the two
disagree in it. Left alone rather than changed silently.

Testing

Built and exercised against a real K4. IambicKeyerTests passes. Not yet built on Windows or
Linux — the layout uses minimum widths rather than fixed pixels for the new controls, but the
wider default fonts there are untested.

[fklassen]

Here are sample screen shots of the updated CW options up to this point.