test: the locked signal list keeps its drag, and the reading says so

Asked for: dragging a signal onto a plot must still work in the compact (view) list. It does — the drag
source is on the *row* and was never conditional on the lock — but nothing said so, and "the lock rebuilds
this list and drops three of its controls" is exactly the change that could take the drag with it. Now it
is a reading: **`drag_sources` must be `rows - 1`**, one per signal row, the `MATH` divider not being
draggable.

    signals panel: … rows=3 signals=2 math=0 divider=1 drag_sources=2      (locked)
    signals panel: … rows=5 signals=4 math=0 divider=1 drag_sources=4      (configuration mode)

Measured the direct way first, with a throwaway walk of the list's rows and
`gtk_widget_observe_controllers()`: `locked=1 rows=3 rows_with_a_drag_source=2`, the third row being the
divider. That is where the number in the reading comes from, and the walk is what found the shape of the
answer rather than assuming it.

One consequence worth recording, because it is an improvement rather than a cost: a locked row can be
dragged from *anywhere* on it, the colour chip included. In configuration mode the chip carries a click
gesture that claims the event sequence precisely so a drag cannot start there (it opens the colour
chooser); the locked list does not build that gesture, so the chip is inert and the row's drag source
sees the press.

What the lock does *not* change is which signals are listed: only the ones that are on. A signal nobody
acquires draws nothing on a plot, so a row for it would be a drag that ends in an empty slot.

Verified: both lines above, from sessions differing only in whether one exists; `make test-ui` 14 files;
zero `Gtk-CRITICAL`. Docs: the `drag_sources` field with what a `0` would mean, the invariants' lock
bullet, and the README's note.

src/ui.cpp

@@ -5747,12 +5747,13 @@ int run_ui(int argc, char** argv, const Config& cfg, ScopeModel& model, Acquisit
       // ones, and the `MATH` divider plus the math channels account for the rest -- so
       // `rows == signals + 1 + math` is the invariant, and `divider=0` is a list that lost its `+`.
       std::printf("[udpscope]   signals panel: labels=%d list=%d rows=%d signals=%zu math=%zu "
-                  "divider=%d\n",
+                  "divider=%d drag_sources=%d\n",
                   labels, lists, app.dbg_signal_rows, app.dbg_signal_plain, app.math.size(),
                   app.dbg_signal_rows ==
                           static_cast<int>(app.dbg_signal_plain + 1 + app.math.size())
                       ? 1
-                      : 0);
+                      : 0,
+                  app.dbg_signal_drag_sources);
     }
     {
       // The events pane's frame, read from the window: the four widgets the `.ui` gives it, and the list

src/ui_app.hpp

@@ -820,6 +820,8 @@ struct App {
   /// of them are streamed signals. The `MATH` divider and the math channels account for the rest, and
   /// `rows == signals + 1 + math` is the invariant the dump checks -- a list that lost its `+`.
   int dbg_signal_rows = 0;
+  /// How many rows of the list carry a `GtkDragSource`: `rows - 1`, the divider not being draggable.
+  int dbg_signal_drag_sources = -1;
   std::size_t dbg_signal_plain = 0;
   int dbg_side_column_after_hide = 1;
   std::string dbg_mode_triggered;

src/ui_probe.cpp

@@ -85,6 +85,24 @@ gboolean exit_probe_step3(gpointer user) {
     a->dbg_switcher_w = gtk_widget_get_width(a->side_switcher);
     a->dbg_switcher_h = gtk_widget_get_height(a->side_switcher);
   }
+  // How many rows of the signal list carry a drag source: dragging a signal onto a plot is how a plot is
+  // filled, so it has to survive both pane modes -- the locked list drops the tick, the menu and the `+`,
+  // and this is the reading that says it did not drop the drag with them. One row is the `MATH` divider,
+  // which is not draggable: the count must be `rows - 1`.
+  if (a->signal_list != nullptr) {
+    int sources = 0;
+    for (GtkWidget* r = gtk_widget_get_first_child(a->signal_list); r != nullptr;
+         r = gtk_widget_get_next_sibling(r)) {
+      GListModel* controllers = gtk_widget_observe_controllers(r);
+      const guint n = controllers != nullptr ? g_list_model_get_n_items(controllers) : 0;
+      for (guint i = 0; i < n; ++i) {
+        GObject* c = G_OBJECT(g_list_model_get_item(controllers, i));
+        if (GTK_IS_DRAG_SOURCE(c)) ++sources;
+        g_object_unref(c);
+      }
+    }
+    a->dbg_signal_drag_sources = sources;
+  }
   // The panes' own switches, and *both* directions of the sync: the header bar's trigger button is
   // flipped here and the pane's switch has to follow, then the cursors' switch is driven from the
   // pane and the button is what has to follow. Both are read back after the fact, so the two pairs in