feat: nested zones (zones as members of zones, denormalised on export)

[pskillen]

Problem

OpenGD77 (and CPS formats generally) model a zone as a flat list of channels. Operators often want hierarchy: e.g. zones Glasgow and Edinburgh, plus a parent zone Scotland that should contain everything in both. There is no way to express this today, and the vendor format cannot represent nesting.

Intended outcome

Allow a zone to include other zones as members, as an application-only concept:

• A zone's members may be channels and/or other zones (referenced by internal id, building on the ID-based model from feat: genericise CPS import via internal data models #7).
• The structure must be acyclic (a DAG / forest): a zone cannot contain itself directly or transitively.
• Tools resolve a zone's effective channel set by recursively flattening child zones and de-duplicating by channel id (stable order).
• At the export boundary the hierarchy is denormalised to a flat channel list per the target CPS version (the radio only ever sees channels). Example: writing Scotland emits the de-duplicated union of Glasgow + Edinburgh channels.
• Not importable: vendor exports are flat, so a round-trip import cannot reconstruct the hierarchy. This is an accepted compromise — nesting is created and maintained only inside the app.

Behaviour details

• Cycle prevention: reject or ignore any membership edge that would introduce a cycle; surface a clear validation error in the UI.
• Effective membership: union of the zone's own channels and the effective channels of each child zone, de-duplicated by channel id, order-stable (depth-first, parents' own channels first is a reasonable default — finalise during design).
• Vendor limits on export: flattening can exceed CPS per-zone limits (e.g. OpenGD77's ~80-channel zone cap). Detect and warn (and/or document) when a denormalised zone overflows the target's limit.
• Map/report tools should visualise/aggregate using the effective (flattened) channel set.

Affected tool(s)

• Internal data model + shared zone-resolution helpers consumed by tools/ (map first), export (feat: CPS export support (internal models → vendor format) #8), and any report/CRUD tools.

Notes / dependencies

• Builds on feat: genericise CPS import via internal data models #7 (internal data models with stable ids and id-based relationships). feat: genericise CPS import via internal data models #7 keeps zones flat (channels only) but its ID-based design already accommodates adding zone→zone references without a relationship rewrite.
• Pairs with feat: CPS export support (internal models → vendor format) #8 (export): denormalisation/flattening lives at the export boundary.
• Pairs with feat: hierarchical codeplug projects + revamped import/export UI #31 (projects) and feat: persist state in browser LocalStorage #9 (persistence): nested structure is part of the persisted internal model.
• App-only concept; SPA (Vite + React + TS).

Out of scope

• Importing/reconstructing nesting from flat vendor exports.
• CRUD UI for building hierarchies is a separate concern if it grows large (can be split out).