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-gtk-and-chrome.md

@@ -245,13 +245,16 @@ Part of [CLAUDE.md](../../CLAUDE.md). These are rules that cost a defect to lear
   alone (`sidebar_wanted`) and the dock's *sensitivity* from `have_signals`; the toolbar's Dock button stays
   sensitive throughout. The wish is persisted (`dock = true|false` in the session file) and a change of it
   schedules a save. `dock:` in the dump reads the result.
-- **An *overlaid* sidebar covers the plot, so a drag out of it has nowhere to land.** `collapsed` in an
-  `AdwOverlaySplitView` means the sidebar sits *on* the plot rather than beside it: the pointer is over the
-  list, never over a drop target, and a signal can be dragged but not dropped. `row_drag_sidebar()` hides
-  the sidebar on `drag-begin` and restores it on `drag-end` — only when collapsed, because side by side the
-  plot is already visible and hiding the list the drag started in would be startling. `pane drag: sidebar
-  hidden for the drag=1 restored after it=1` is the reading; the state is forced collapsed the way the
-  sidebar probe forces it.
+- **The signal badge is the drag handle, and a drop handler only moves widgets.** Dragging a signal onto a plot
+  starts on its badge in the badge bar (a `GtkDragSource` on the badge's button, payload the signal index as a
+  decimal string, taken by the plot area's existing drop target); the list's rows are not drag sources. A drag
+  starting with the slide-over open would have part of the plot hidden under the panel, so the source's
+  `drag-begin` closes it (which only restyles the badges: nothing is destroyed mid-drag). A click without movement
+  never reaches the drag threshold and still opens the page; past it the source claims the sequence and the
+  button's click is cancelled. Each badge is also a `GtkDropTarget` for reordering: `on_badge_drop` calls
+  `gtk_box_reorder_child_after` and rewrites `App::badge_order` from the widgets, and **never rebuilds the badges** --
+  the dragged badge and the target whose `drop` emission is running must both survive it. A foreign drag whose string is not a
+  signal index is refused. `[sigbadges]` reads the controllers, the payload and the reorder; `pane drag:` reads the close.
 - **A stock icon name has to be one *Adwaita* has, and a blank button is the failure mode.** The two
   panes' `[edit]` buttons are `document-edit-symbolic` (the pencil: edit) and `object-select-symbolic`
   (the check: done). The done one was `emblem-ok-symbolic`, which breeze ships and **Adwaita does not** —

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

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]`
 
 ```