#787 Layer Groups phase 1: group-aware selection + report filters (SF #222/#782 follow-on)

[Allen D Byrne]

Layer Groups phase 1: use groups as a shortcut for layer selection, in canvas selection and report filters (umbrella #222, builds on phase 0 #782).

Phase 0 (#782) shipped the data model, Manage Layer Groups dialog, and a "Show Only" visibility action -- but groups aren't usable anywhere else yet: no reference to LayerGroup exists in cselect.c (track selection), cprint.c (printing), dxfoutput.c (export), or reports.c/reportsformat.c (any report). This phase makes groups a real shortcut for layer selection at two sites:

1. Canvas selection: a new "Select Layers/Groups..." action generalizing the existing SelectCurrentLayer()/DeselectLayer() (cselect.c), which today only operate on the single current layer.

2. Reports filter: add the same picker as a new filter control to every existing report dialog (Track Lengths, Turnout, Curve Stats, Equipment -- reports.c). None of these have any scope/filter control today; each unconditionally walks every track via TrackIterate()/GetTrkLayer() on Refresh. Filter defaults to "all layers" (unchanged existing behavior). Group membership is re-resolved fresh on every Refresh, so a filter never goes stale relative to later group-membership edits.

Key design decision: a group is a one-shot preset, not a stateful list entry. The only real state in either picker is a flat per-layer checklist (same state you'd have without groups at all). Applying a group just checks/unchecks that group's current members' boxes at the moment it's applied; every box stays independently toggleable afterward, so deselecting one member of an applied group works like deselecting any other layer. No live link is kept between the checklist and the group. (Rejected alternative: a group as a live/compound list entry supporting per-member exclusion -- real set-algebra for what's meant to be a shortcut, more machinery than warranted.)

No file-format or persistence changes -- reuses #782's existing LayerGroupCount()/LayerGroupMemberAt()/LayerGroupHasMember() API as-is. Independent of Op Density: doesn't require #782 merged into Hg mainline first, and doesn't block on Op Density's own work.

Full design writeup: .claude/layer-groups-feature-design-2026-09-06-v1.md, "Phase 1 (2026-09-09)" section.

[Allen D Byrne]

Phase 1 complete: git PR #184 merged into GTK3V2MAIN (26/26 CI green, astyle-check fixed same session), Hg bug branch bug-787-layer-groups-selection-filters-gtk3 now pushed to SF (4 commits, tip 8165dea971ef, built on #782's phase-0 tip).

Delivers two sites: (1) a new Select Layers/Groups dialog generalizing layer selection to an arbitrary set of layers/groups; (2) group-aware Available/Included filters added to all 7 Reports dialogs. Both live-verified via Xvfb and against a real layout (NYE, 18 layers). Design doc: .claude/layer-groups-feature-design-2026-09-06-v1.md, Phase 1 section.

Depends on phase 0 (#782), which is itself still needs-review -- this branch is held out of Hg mainline pending #782's own review/merge, same as #782 itself.

[Allen D Byrne]

Correction to my previous post: git PR #184 is NOT yet merged into GTK3V2MAIN -- I
stated that incorrectly (conflating it with an unrelated PR that did merge this session). PR #184
is open with CI green (27/27) as of this correction. The Hg branch push described above is
accurate and already done. Will follow up once PR #184's merge status is actually resolved.

[Allen D Byrne]

Follow-up: PR #184 is now actually merged into GTK3V2MAIN (27/27 CI green), so the earlier premature claim is now correct in fact. Git and Hg (bug-787-layer-groups-selection-filters-gtk3, pushed to SF) are consistent. Still held out of Hg mainline pending #782 review, same as before.