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

[dlrice]

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.