Tame Nightingale's click-highlight fill swap on collapsed group aggregate tracks

**Context** Every `<nightingale-track-canvas>` we render — both the collapsed-group aggregate track and each expanded detail track — is mounted with `highlight-event="onclick"`. That attribute opts the track into Nightingale's built-in click-highlight behaviour: clicking a feature swaps its solid fill for a border-only "selected" state, and broadcasts the highlight range via `<nightingale-manager>` so other mounted components can co-highlight the same region. This is longstanding Nightingale behaviour — visible on the currently-shipped production viewer at `https://www.uniprot.org/uniprotkb/P05067/feature-viewer`, and present at every point on the config-approach branch we bisected (from `945ca9f` forward). It is not a regression introduced by any commit on the branch. The visual effect is functionally correct but perceptually jarring on the collapsed-group aggregate view specifically. The aggregate flattens every child track into a single dense canvas; when a feature is clicked there, the feature at the group-wide scale loses its fill and shows as a hollow outline. In the expanded detail view the same fill-swap happens, but the user's eye reads it as "that feature is selected now" because the context is clearer; in the aggregate view it reads as "something glitched." The most common visible offender is a `BINDING` feature in the `SITES` group's collapsed aggregate, but any feature on any canvas track can trigger it. **Task** Decide how the collapsed aggregate should visualise a click — keep the Nightingale default, suppress it on the aggregate only, or retheme the selected state to retain a fill. Implement the chosen path and regression-test against the live uniprot.org visual as the reference point. **Scope:** Three options with different cost/reward profiles; pick one before opening the PR: 1. **Drop `highlight-event="onclick"` from the aggregate-track render in `getTrack`.** Keep it on the detail-track render. Collapsed clicks then open the tooltip without toggling a selected state, and the feature stays filled. Smallest code change — a single conditional in `src/protvista-uniprot.ts` that threads "is this call rendering an aggregate?" into `getTrack`. Trade-off: cross-track highlight-sync via `<nightingale-manager>` is also disabled for aggregate clicks, so if a click on the aggregate should propagate to the expanded view (not today's UX, but a plausible future one), this path precludes it. 2. **Retheme the Nightingale selected state via CSS override.** Keep `highlight-event="onclick"` everywhere (preserves manager-driven sync) but target the class/attribute Nightingale writes for the selected feature and restore a fill. Requires inspecting the Nightingale-emitted DOM under DevTools to identify the selector, then adding the override in `src/styles/protvista-styles.ts` under the existing `protvista-uniprot` tag scope. Middle effort. Trade-off: selector is an implementation detail of Nightingale and could break on future upstream upgrades. 3. **File upstream on Nightingale.** Ask the Nightingale team to expose the selected-state visuals as CSS custom properties (`--nightingale-feature-selected-fill`, `--nightingale-feature-selected-stroke`) so consumers can theme the state without hacking internal selectors. Right answer long-term; timing depends on Nightingale's release cadence. Pair with option 2 as the interim fix while the upstream PR lands. Acceptance: * The binding-site fill → border-only toggle no longer occurs on the collapsed aggregate view of the `SITES` group (and every other canvas-track group with the same click shape). Verify at `accession=P05067` across all 15 default groups. * Click-triggered tooltips still fire on the aggregate track (the fix must not suppress the tooltip). * Expanded-view click behaviour is unchanged (features still highlight in their own track, tooltips still open, cross-track manager sync continues to work). * A snapshot or DOM test exercising the collapsed-click → feature-element-attributes path so this doesn't silently regress again. **Notes:** The bisection summary is worth recording for future maintainers: multiple bisection attempts across the config-approach branch (`945ca9f` through HEAD) all landed on commits that either don't touch runtime code (`20016c6`, `f5dcef2`) or touch unrelated runtime paths (`cd3e295` — tooltip arrow borders only). The bug does not originate on this branch; it is a pre-existing Nightingale behaviour that the branch inherits. A fix here is a *visual quirk repair*, not a regression repair. Before touching `highlight-event`, verify what manager-driven highlight-sync is actually used for in production. If no consumer depends on a click-in-aggregate triggering a highlight elsewhere, option 1 (strip the attribute from the aggregate) is clean and forward-compatible with either of the other options if the need emerges later. If cross-track sync from the aggregate is ever a requirement, lean on option 2 + 3. Side note: the perceptual asymmetry between the collapsed and expanded views also suggests a broader UX question — whether a click on an aggregate-rendered feature should do anything at all beyond open a tooltip, given the feature "lives" on one of the detail tracks. That's out of scope for this issue but worth a separate design conversation if it comes up again.