ui: the signal badge is the drag handle (to a plot row, or to reorder); the list rows stop dragging

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

docs/claude/invariants-session-and-export.md

@@ -18,11 +18,10 @@ Part of [CLAUDE.md](../../CLAUDE.md). These are rules that cost a defect to lear
   a control that changes the configuration. A *first run* — no session file for that source — never
   reaches `apply_layout()` and stays in configuration mode, which is what a first run is for. The mode
   is a mode and not a setting: it is deliberately not persisted, so a scope reopened tomorrow starts
-  where a returning user expects to start. **Dragging a row onto a plot is not configuration and survives
-  the lock**: filling plots is what the list is *for*, so a locked row keeps its `GtkDragSource` — from
-  anywhere on it, the colour chip included, which in configuration mode has a click gesture that claims
-  the sequence precisely so a drag cannot start there. `drag_sources` on the `signals panel:` line is the
-  reading, and it must be `rows - 1`.
+  where a returning user expects to start. **Dragging a signal onto a plot is not configuration and survives
+  the lock**: it is the signal *badge's* drag (the list's rows are no longer drag sources, and the badges do
+  not follow the lock). `[sigbadges] drag_sources` is the reading, and `drag_sources` on the `signals panel:`
+  line must be 0.
 - **The session is the layout.** `LayoutState` persists what makes a reopened scope look like the
   one that was closed: the window, the rows and their slot signals, the calibration, **the enabled
   signals**, **the chosen trace colours** (`[[color]]`, `name` + `rgb = "#RRGGBB"` — only the