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/probe-readings.md

@@ -1703,18 +1703,21 @@ library measures and draws the rect in tests of its own.
 ## `panes:` — the locked and configuration modes
 
 ```
-[udpscope]   pane drag: sidebar hidden for the drag=1 restored after it=1
+[udpscope]   pane drag: slide-over closed for the drag=1
 [udpscope]   pane edits: locked=document-edit-symbolic(ok) config=object-select-symbolic(ok)
 [udpscope]   panes: trigger=locked signals=locked body_visible=0 summary='signal: square | condition: window, falling | level: 0.3 .. 0.6 | mode: single | noise band: 0.2 | pre-trigger: 20 % | hold-off: 1000 ms'
 [udpscope]   panes: trigger=config signals=config body_visible=1 summary=''
 [udpscope]   panes: the same line as the probe found it: 'mode: stream (trigger off)'
 ```
 
-**`pane drag:`** is a drag begun through the *source* with the split view forced into its **overlaid**
-state, which is what a window with no room beside the plot produces. Both must read `1`: with the sidebar
-covering the plot there is no drop target under the pointer, so a drag out of the signal list is
-*impossible* rather than merely awkward, and `row_drag_sidebar()` steps the sidebar aside for the length of
-the drag and puts it back after. `hidden=0` is an overlaid drag that can never land anywhere.
+**`pane drag:`** is a drag begun through the *source* of the first signal badge (`drag-begin` emitted on its
+`GtkDragSource`, so the handler is the one a real drag reaches) with the `signals` slide-over page open. It
+must read `1`: the slide-over covers the plot's right edge, so a drag that started with it open would have part
+of the plot that is not a place to drop, and the badge's `drag-begin` closes it. (The page that was open is put
+back afterwards.) `0` is a drag that leaves the panel over the plot; `-1` is no badge to drag (no signal enabled,
+or more than six, where the badges are replaced by the "N signals" overflow). It replaced the old
+`sidebar hidden for the drag=1 restored after it=1` pair, which tested `row_drag_sidebar()` -- the list rows were
+the drag handle and the overlaid sidebar had to step aside; both are gone.
 
 **`pane edits:`** is the two `[edit]` buttons in each mode, by name and verdict, and it exists because of
 a real defect: the "done" icon was `emblem-ok-symbolic`, which **Adwaita does not have** (breeze does), so
@@ -2309,10 +2312,9 @@ The signals panel's frame read from the window, and in the same line the *shape*
 the heading and the hint the `.ui` gives it, the list the rows go in, how many rows that list holds
 (`rows`), how many of them are streamed signals (`signals`), how many math channels the app has (`math`),
 and `divider`, which is 1 when `rows == signals + 1 + math` and 0 otherwise. **`drag_sources` must be
-`rows - 1`** — one per signal row, the `MATH` divider not being draggable. 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 the drag did not go with them. (`0` is a list that has become a thing
-you can read but not use.) `labels=1` is a `.ui` that lost
+`0`**: dragging a signal onto a plot is the signal *badge's* job now (see `[sigbadges]`, which counts the
+badges' own sources), and the list's rows only open the signal's page; a non-zero reading is a second, competing
+drag handle on the list. `labels=1` is a `.ui` that lost
 one of the two labels — counted over the panel's subtree *above* the list, because the rows' own name
 and unit labels are the code's and the heading sits in a heading row beside the pane's `[edit]` button — `list=0` one that lost the list -- both of which otherwise show as a panel quietly
 missing a piece -- and **`divider=0` is the merged list that lost its `+`**, the one control that can create
@@ -2666,6 +2668,19 @@ height moved while one signal was switched off and on again (`rebuild_signal_pan
 first signal badge opens `signal:<name>` with the badge marked open and a second click closes it (`-1` when overflowed, there being no signal badges); `plus_opens=1` the same for the "+"
 (the overflow badge when overflowed) and the `signals` page.
 
+```
+[sigbadges] drag_sources=4 drop_targets=4 prepare_ok=1 reorder_before=sine,square,ramp,noise reorder_after=noise,sine,square,ramp reorder_ok=1 payload_drop=1 list_drag=0
+```
+
+The second line is the drag handles. `drag_sources` and `drop_targets` count the `GtkDragSource` / `GtkDropTarget` controllers over all the
+signal badges (each badge carries one of each, so both must equal `badges`; beyond six signals the badges are gone and both read 0). `prepare_ok=1`: the first badge's
+`prepare` returns a provider whose string is its signal index (the payload the plot area's drop target reads; `0` is a drag that carries nothing or the wrong
+signal, `-1` no badge). `reorder_before` / `reorder_after` are the badge names in widget order around a call to the badges' own `drop` handler with the last badge dropped on
+the first; `reorder_ok=1` means the last badge is now first, `badge_order` matches the widgets, and the original order was restored afterwards (so later probes see it;
+`-1` with fewer than two badges). `payload_drop=1`: the signal is taken off the plots and `assign_signal_to_row(signal, 0)`, the call the plot's drop makes, leaves it plotted
+(`-1` no badge). `list_drag` is the number of drag sources on the signal list's first row, and **must be 0**. **A real pointer drag cannot be simulated headless**: the
+gesture's threshold, the slide-over closing under it and the pointer-driven drop are untested here; the line reads the controllers, the payload, the reorder and the assignment.
+
 ## `[badges]`
 
 ```