feat: support for multi-mode channels

[pskillen]

Problem

Some radios (e.g. the Baofeng DM-32) support dual-mode channels — a single channel entity that carries both analog and digital configuration. Other radios (e.g. OpenGD77) require these to be modelled as two separate channels with distinct names and CPS rows.

Today our internal model assumes one mode per channel. Operators who think in terms of "one repeater, FM or DMR" must manually duplicate channel data or maintain parallel entries.

Intended outcome

Let a single logical channel represent a multi-mode entity in our internal data models, and denormalise into the vendor-specific channel rows required at the export boundary.

Modelling

• Per-channel opt-in flag (e.g. multiMode or similar) — when off, behaviour is unchanged (single mode per channel).
• When enabled, the channel carries multiple mode configurations (e.g. FM + DMR sharing common identity: name/callsign/location/frequencies where applicable, with mode-specific fields nested or keyed by mode).
• Exact schema to be finalised during design; should compose cleanly with the richer mode enum from the mode-field refactor issue.

Export (required)

• At export time, expand a multi-mode logical channel into n concrete vendor channels — one per mode the target CPS cannot combine.
• Naming scheme: deterministic, collision-resistant, respecting CPS channel-name length limits and case-sensitive foreign-key rules (similar design questions as feat: multi-talkgroup channels (denormalise one channel into repeater × talkgroup pairs on export) #36).
• Zone membership: decide whether a zone referencing a multi-mode channel expands to all generated children (mind OpenGD77 ~80-channel zone cap, as with feat: nested zones (zones as members of zones, denormalised on export) #33).

Import (best-effort, NOT a blocker)

• On import, best-effort merge of related vendor channels back into one logical multi-mode channel — e.g. group by shared name stem + rx/tx frequencies + location, differing only by mode/type.
• Explicitly not required to ship export-side support.
• Vendor exports are flat and lossy; mis-grouping is acceptable. If merge fails, channels arrive as separate rows (no regression).

Pattern

This mirrors #36 (multi-talkgroup channels): model intent cleanly internally, denormalise at the vendor boundary, optional re-normalisation on import.

Concept	#36	This issue
Logical entity	One channel, many talk groups	One channel, many modes
Denormalise on export	channel × TG pairs	channel × mode rows
Import	Best-effort collapse by name + freqs + varying TG	Best-effort collapse by name + freqs + varying mode

Affected

• Internal data model (src/models/) — multi-mode flag + per-mode configuration
• Export layer (feat: CPS export support (internal models → vendor format) #8) — denormalisation lives here
• Import (feat: genericise CPS import via internal data models #7) — optional best-effort re-normalisation
• CRUD channels (feat: CRUD channels #11) — UI to enable multi-mode and edit per-mode fields
• Map/report (feat: tabular/visual report of CPS data (read-only) #6) — one marker vs expanded representation

Notes / dependencies

• Builds on feat: genericise CPS import via internal data models #7 (internal models with stable ids) and the mode field refactor (specific FM/DMR/… values).
• Pairs with feat: CPS export support (internal models → vendor format) #8 (export) and feat: multi-talkgroup channels (denormalise one channel into repeater × talkgroup pairs on export) #36 (same denormalise-at-boundary pattern).
• DM-32 is the primary motivating radio; OpenGD77 likely always exports as separate channels.

Out of scope

• Changing radio firmware behaviour.
• Guaranteed loss-free import re-normalisation.

Workflow note

Likely multi-commit work: branch from origin/main, atomic conventional commits, PR linking Closes #. Pair with docs/features / progress-tracking skills.