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/layout_store.hpp

@@ -32,6 +32,15 @@ struct LayoutState {
   };
   std::vector<Calibration> calibration;
 
+  /// The trace colours the user chose, `0xRRGGBB`. Only the *overrides*: a signal with no entry
+  /// takes the positional palette entry, which is what keeps a stream's new signals coloured
+  /// without a session having to name them. Saved by name like every identity here.
+  struct Color {
+    std::string name;
+    std::uint32_t rgb = 0;
+  };
+  std::vector<Color> colors;
+
   /// Signals the session had enabled. Enabling is what starts acquisition, so this is what makes a
   /// reopened scope look like the one that was closed -- and it is saved by *name*, like every other
   /// identity here, because a CONFIG renumbers the channels.