fix: persistence is the trace's own phosphor, not a density behind a stroke

The plotter now deposits every acquisition -- the newest included -- into one grid per trace and
draws no solid trace over it, each grid in that trace's colour and with a one-sweep ceiling (its own
commit, **1b8b55d**). This side needed almost no change of its own, because the colour was already
the trace's and the trace's colour is `RowSet::signal_color()` -- the invariants' one route -- but the
figures it reads back are now per trace:

- **The ceiling is left at the library's default of one sweep**, no longer derived from the fade.
  Deriving it from the steady state is the gain offset the user reported between the latest
  acquisition and the persistent image; a signal crossing the same place every acquisition now settles
  at the trace's colour, at full strength, and the newest sweep reads as the trace it is a picture of.
- **`cells`/`grid_bytes` are the sum over the row's traces** -- one grid each, a trace with no series
  holding none -- and both the probe and the exit dump carry `traces=` beside `rows=`. That is what
  makes the per-signal memory figure read: **556 537 cells and 2.2 MB per signal**, at 8904600 bytes
  over the four one-signal rows of the probe's run.

The probes, re-read on this build (the `verification.md` command, `--rate 500000 --batch 1000`):

    [density-probe] off enabled=0 ... rows=0 traces=0 cells=0 ink=0.0 peak=0.0000
    [density-probe] on enabled=1 ... rows=4 traces=4 cells=2226150 ink=226786.0 peak=1.0000
    [density-probe] step-acquisitions ... peak=1.5000
    [density-probe] time-before ... peak=2.1359
    [density-probe] step-time ... ratio=0.367879
    [density-probe] frame cost: tick 0.62 -> 6.96 ms (184/23 frames), draw 2.02 -> 6.16 ms (177/18)
    [udpscope]   density: frames=748 rows=4 traces=4 cells=2226150 grid_bytes=8904600 ink=489400.2 peak=2.2 upload_bytes=2226150

`on` `peak=1.0000`, `step-acquisitions` `peak=1.5000` and `step-time` `ratio=0.367879` are the legs
that were expected, unchanged; the *draw* mean is now **below** the run before the split (2.02 -> 6.16
against 2.09 -> 20.91), because the solid traces are no longer drawn over the image.

Docs updated with it: the trigger manual page (`persistence` is the trace, one image per signal, the
newest included), the README's persistence section, `invariants-trigger-and-pinning.md` (five rules,
the ceiling and the no-stroke rule among them), `verification.md` and `probe-readings.md` (the lines
above), the trigger panel's comment and tooltips, and the plotter submodule.

`cmake --build build --clean-first -j4`: **0 errors, the documented three warnings** (two
`MathNode::source`, one `-Woverlength-strings` at 12352); `make -C build test-ui` **13 ok**;
`make -C build test-help` **green** (15 pages); the self-check **0 `Gtk-WARNING`/`Gtk-CRITICAL`** and
`gtk warnings: 0`, two `buffer allocated:` lines.

docs/claude/probe-readings.md

@@ -1980,53 +1980,61 @@ ring's bindings, and a reading taken there says nothing about either.
 
 ```
 [density-probe] arming on 'square', window 0.5 s, display off
-[density-probe] off enabled=0 fade=acquisitions tau=1.000 factor=0.500 rows=0 cells=0 ink=0.0 peak=0.0000 ratio=1.000000
-[density-probe] on enabled=1 fade=acquisitions tau=1.000 factor=0.500 rows=4 cells=2226150 ink=226596.0 peak=1.0000 ratio=1.000000
-[density-probe] step-acquisitions enabled=1 fade=acquisitions tau=1.000 factor=0.500 rows=4 cells=2226150 ink=262722.0 peak=1.5000 ratio=1.159429
-[density-probe] time-before enabled=1 fade=time tau=1.000 factor=0.500 rows=4 cells=2226150 ink=213362.2 peak=1.2182 ratio=1.000000
-[density-probe] step-time enabled=1 fade=time tau=1.000 factor=0.500 rows=4 cells=2226150 ink=78491.6 peak=0.4481 ratio=0.367879
-[density-probe] frame cost: tick before=0.74 ms (163 frames) after=9.99 ms (12 frames) draw before=2.09 ms (157) after=20.91 ms (7)
-[udpscope]   density: frames=504 rows=4 cells=2226150 grid_bytes=8904600 ink=632845.4 peak=2.8 upload_bytes=1081350
+[density-probe] off enabled=0 fade=acquisitions tau=1.000 factor=0.500 rows=0 traces=0 cells=0 ink=0.0 peak=0.0000 ratio=1.000000
+[density-probe] on enabled=1 fade=acquisitions tau=1.000 factor=0.500 rows=4 traces=4 cells=2226150 ink=226786.0 peak=1.0000 ratio=1.000000
+[density-probe] step-acquisitions enabled=1 fade=acquisitions tau=1.000 factor=0.500 rows=4 traces=4 cells=2226150 ink=313971.0 peak=1.5000 ratio=1.384437
+[density-probe] time-before enabled=1 fade=time tau=1.000 factor=0.500 rows=4 traces=4 cells=2226150 ink=458610.1 peak=2.1359 ratio=1.000000
+[density-probe] step-time enabled=1 fade=time tau=1.000 factor=0.500 rows=4 traces=4 cells=2226150 ink=168713.2 peak=0.7858 ratio=0.367879
+[density-probe] frame cost: tick before=0.62 ms (184 frames) after=6.96 ms (23 frames) draw before=2.02 ms (177) after=6.16 ms (18)
+[udpscope]   density: frames=748 rows=4 traces=4 cells=2226150 grid_bytes=8904600 ink=489400.2 peak=2.2 upload_bytes=2226150
 ```
 
 The **phosphor density** (`Plot::set_density()`, the trigger pane's `persistence` switch): one
-screen-sized intensity image per row, every acquisition accumulated into it, drawn behind the traces and
-fading by a count or by the clock. The numbers are the plotter's own -- `DensityGrid::ink()`/`peak()` summed
-and maxed over the rows the display is on, which is the same source the library's tests read -- and the
+screen-sized intensity image **per trace**, in that trace's own signal colour, every acquisition
+accumulated into it (the newest included), drawn *in place of* the traces and fading by a count or by
+the clock. The numbers are the plotter's own -- `DensityGrid::ink()`/`peak()` summed and maxed over the
+traces the display is on, which is the same source the library's tests read -- and the
 probe drives the panel's **own widgets** for the switch and the fade, so what it measures is this app's
 wiring.
 
-- **`off` is the display without it**: `rows=0`, so there is no grid at all and both numbers are zero.
-  That is also the run the frame cost is read against, and it is a plain run -- the density is off by
-  default and nothing draws it.
-- **`on` is one sweep**: `peak=1.0000` exactly, and `ink=226596` is the cells that sweep covered over
-  four rows. A cell takes **1.0 once per trace per sweep** however many of the trace's own samples crossed
-  it, which is what makes a sweep's peak *one* rather than the eighteen a per-hit deposit read on the same
-  run -- and what makes the sweeps behind it visible at all.
+- **`off` is the display without it**: `rows=0 traces=0`, so there is no grid at all and both numbers
+  are zero. That is also the run the frame cost is read against, and it is a plain run -- the density
+  is off by default and nothing draws it.
+- **`on` is one sweep**: `traces=4` -- one grid per signal, four rows of one signal each -- and
+  `peak=1.0000` exactly, with `ink=226786` the cells that sweep covered. A cell takes **1.0 once per
+  trace per sweep** however many of the trace's own samples crossed it, which is what makes a sweep's
+  peak *one* rather than the eighteen a per-hit deposit read on the same run -- and what makes the
+  sweeps behind it visible at all.
 - **`step-acquisitions`** deposits one more sweep: `peak=1.0000 -> 1.5000`, which is `1 + 0.5 x 1` -- the
-  panel's factor 0.5 applied to what was there, then the new sweep's own pass on top. `ink` rises from
-  `226596` to `262722` for the same reason: the old image halved and one sweep landed on it. The ratio is
+  panel's factor 0.5 applied to what was there, then the new sweep's own pass on top. The ratio is
   **not** a constant to expect -- the acquisition on screen can move between the two reads, so what it says
   is "the old image halved and a pass landed on it"; the exact relation is the *library's* case
   (`a_density_halves_per_acquisition_and_keeps_the_newest_brightest`), where the same frame is deposited
   twice.
 - **`step-time` is `1/e` by construction**: one step of `dt = tau` through the plot's own `decay_density()`,
   so `ratio=0.367879` is `exp(-1)`. The leg before it (`time-before`) reads the same image under the time
-  fade, and the pair is the reading that says the *panel's* constant reaches the grid.
+  fade (`peak=2.1359`), and the pair is the reading that says the *panel's* constant reaches the grid.
 - **`frame cost:` is the A/B inside one run**: the accumulators as of the tick the display was switched on
   against the frames after it, so both means are the same stream, the same layout and the same mock. At four
-  rows of 573x412 cells it reads **tick 0.74 -> 9.99 ms** and **draw 2.09 -> 20.91 ms**: the per-frame
+  rows of 573x412 cells it reads **tick 0.62 -> 6.96 ms** and **draw 2.02 -> 6.16 ms**: the per-frame
   conversion, upload and deposit. It is llvmpipe, and the arithmetic is the grid's -- 2.2 M cells, one byte
-  each, every frame the time fade moves it.
+  each, every frame the time fade moves it. The *draw* mean is now below the run before the per-trace
+  split (2.02 -> 6.16 against 2.09 -> 20.91): the solid traces are no longer drawn over the image, so the
+  frame draws four quads where it used to draw four quads *and* every trace.
+- **`cells`/`grid_bytes` are the per-signal memory figure**: 556 537 cells and 2.2 MB *per signal*, times
+  the four signals here (2 226 150 cells, 8 904 600 bytes). It is the axes rect's device pixels, so it is
+  the screen and the trace count and nothing the trigger has done -- and the app's default layout, four
+  signals in one row, is four grids for that one row.
 - **The dump's `density:` line** is captured on the last tick the display was **on**, not read at exit: the
   exit probe switches the trigger off before it dumps, which takes the display with it, so a dump that asked
   the plots would say `rows=0` about a run whose tail had the image up. `upload_bytes` is the **most** any
-  one frame uploaded -- one byte a cell, over the rows that moved -- and not the last frame's, for the same
-  reason.
+  one frame uploaded -- one byte a cell **per trace**, over the grids that moved -- and not the last frame's,
+  for the same reason.
 
-**Read `peak` as the display's ceiling**: with the default `full_scale` of 1.0 a cell at 1.0 is full ink, so
-a steady display under the acquisition fade sits between 1 and 2, and a `peak` well above that (the
-per-hit deposit read 189 after two sweeps) is the defect this probe's `on` leg now catches.
+**Read `peak` as the display's ceiling**: with the default `full_scale` of 1.0 a cell at 1.0 is full ink
+(the trace's own colour), so a steady display under the acquisition fade sits between 1 and 2, and a `peak`
+well above that (the per-hit deposit read 189 after two sweeps) is the defect this probe's `on` leg now
+catches.
 
 **And `N = 1` is the display without the feature**, which is the same command at
 `UDPSCOPE_PROBE_PERSIST_DEPTH=1`: