feat: a signal's chip is clickable, so a trace's colour is the user's to choose

Clicking the coloured chip in the signal list opens a GtkColorDialog and the
colour it returns overrides that signal's palette entry. Held by name, like
every other identity here, and persisted as a session `[[color]]` table.

RowSet::signal_color() becomes the one resolver: install() builds the trace
through it and all three chip sites read it, because a chip exists to say which
trace a row is about and an override is exactly the state in which two routes to
a colour would disagree. A grey chip names no trace and so is not clickable, and
the way back is `Default colour` in the signal's menu -- a setting with no undo
is a trap.

The gesture sits on the existing label rather than in a GtkButton: padding on
this row is what made the signal list twice as tall once. It claims its sequence
so a click on the chip cannot become the start of a row drag.

UDPSCOPE_PROBE_COLOR_MS reads the result out of plot::Plot::trace() and out of
the chip's own markup, with an override in no palette slot, so neither leg can
pass by asking the resolver what it already said.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

src/help/03-signals.txt

@@ -22,6 +22,9 @@ the overflow menu opens the editor where the unit and the calibration live.
 • A signal's colour follows the <i>signal</i>, not the slot, so the same signal on two rows
   is one colour and the side panel's chip identifies it unambiguously. A signal on no row
   gets a grey chip rather than none, so the panel's rows keep their height.
+• <b>Click a coloured chip to change that signal's colour.</b> A grey chip names no trace, so
+  it is not clickable. The colour is saved with the session; <b>Default colour</b> in the
+  signal's ⋯ menu gives the palette entry back.
 
 <b>Example</b>