measure: the split's own means are back as above/below/between

`top`, `bottom` and `amplitude` became the *flat levels* in e83ad86 -- the level the
signal dwells at, read from the density of the window's buckets -- and that change kept
the split's own two means as its internal fallback for a window the pyramid cannot
summarize. Those means are now three types of their own, so the two different questions
about one split can be asked side by side: `above %` and `below %` are the plain mean of
the samples on one side of a share -- the reading the old `top`/`bottom` gave -- and
`between % %` is the mean of the band between two shares, which no single split can
answer, because a band's two edges are two thresholds.

Nothing about the arithmetic is new, and nothing is a new pass. `Above`/`Below` are the
`sum[]`/`count[]` split `measure_accumulate()` already folds -- the very figures
`Top`/`Bottom` fall back to -- and `Between` is the **difference of two levels' upper
sides**, both of which come out of one pass two over one window. It rides the bucket
fast path unchanged: a bucket wholly inside the band is strictly above the lower level
and strictly below the upper one, so both accumulators fold it whole, and only the
buckets that straddle either edge are opened. `measure_level_pcts()` is the one place the
shares are read, and it clamps both and puts `between`'s pair **in order**, so "between
80 % and 20 %" is the band between 20 % and 80 % -- normalized rather than refused,
because the shares name two edges rather than a direction. Nothing to measure reads `--`,
as for every other type: a share at 100 % has no sample above it, and a band can hold
none at all.

Measured, `[bandavg-probe]`, fast mock at a 2 s window (`--rate 1300000 --batch 1000
--freq 1`):

  sine   `above 50` 0.636620 (2/pi), `below 50` -0.636620, `between 50 75` 0.255873
  square `above 50` 0.986496 (30 harmonics) / 1.000000 (--square-harmonics 0),
         `between 50 75` 0.302744 / --
  ramp   `between 50 75` 0.250000 and `above 50` 0.500000, `above 100` --

The first three are the figures the old `top`/`bottom` documented; the ramp's are what a
uniform density predicts (a band's mean is its own centre); the ideal square's empty band
is the nothing-to-measure rule. The pane offers the types and edits their percentages
through the dialog's second share -- which only `between` shows -- and a measurement's
pair survives add/edit/delete and the session file (`threshold2`), where a file written
before it existed loads at the default.

No raw pass: with the measurements probe adding one of every type at a 2 s window, `raw`
went from 113966 of 240719031 covered (0.0%) to 134978 of 255372033 (0.1%), 0.8 -> 1.1
ns a covered sample.

Docs: the band-average invariant (and the two assertions the flat-level change moved),
the probe readings for the new probe, the verification recipe, the manual's measurements
page and the README.

docs/claude/probe-readings.md

@@ -218,6 +218,9 @@ Two lines of the self-check output are assertions in disguise:
   pane_h=H switch_on=X reset_sensitive=Y`
   (stderr, `UDPSCOPE_PROBE_MEASURES_MS`) — adds one measurement of every type on the first
   plottable signal and lets the tick compute them, so what it prints is what a user reads.
+  The dump line carries one more field for the one type that reads *two* shares:
+  `measure N: 'sig' between thr=50.0% thr2=75.0% above=1 show=1 -> ok ...`, where `thr2` appears
+  only for `between` (see the band-average probe below).
   On the test stream's 1 Hz ±1 sine the values must be: average ≈ 0, `top` ≈ 0.96 and
   `bottom` ≈ -0.96, `amplitude` ≈ 1.92, max/min ≈ ±1, `peak to peak` **exactly 2**,
   `pulse duration` ≈ 0.5 s
@@ -226,7 +229,9 @@ Two lines of the self-check output are assertions in disguise:
   window rather than from a mean over a side, and a sine has no plateau — so the densest band
   sits at its peak and the reading is near it, not the 0.636620 a mean over a half would give.
   `amplitude` is that pair's delta (`top - bottom`), which is why it reads about 1.92 rather than
-  the half-swing it used to: a bench scope's `Vamplitude` is `Vtop - Vbase`. The measured
+  the half-swing it used to: a bench scope's `Vamplitude` is `Vtop - Vbase`. The mean over a half
+  is not gone, though: it is `above 50` on this stream (and `-above 50` is `below 50`), and its
+  own probe asserts it — see `[bandavg-probe]` below. The measured
   figures, and the reason they are what they are, are in
   [invariants-measurements.md](invariants-measurements.md) — on the mock's `square` the
   separation is the visible one (`top`/`bottom` `0.999983`/`-0.999983`, `amplitude` `1.999966`,
@@ -275,10 +280,15 @@ Two lines of the self-check output are assertions in disguise:
   (`an_unselectable_cursor_is_neither_hovered_nor_grabbed`) is the other half. The probe's last
   step still drags a mark *programmatically* and requires the next frame to put it back
   (`restored=1`), which now checks the placement path rather than the read-only property. The dialog report's `type= thr=
-  side= show=` is the per-type behaviour: `period` and `frequency` must show **neither** the
+  band= side= show= shares=A/B` is the per-type behaviour: `period` and `frequency` must show **neither** the
   split nor the side row (they compute from the mid level's rising crossings, and an option
   there is one the user can only get wrong), `average`/`min`/`max` no split either, and only
-  `pulse duration` a side. A measurement whose signal is not acquired, or
+  `pulse duration` a side. `band` is the *second* share's row, which only `between` shows -- it is
+  the one type whose two edges are both parameters -- and `shares` is what the two spin fields are
+  *showing*, read back out of the widgets: a share that is stored but not seeded into its field, or
+  a field that is built but not read back on apply, is then visible in this line rather than only in
+  the reading it produces. `above`/`below` show the threshold row and no band row, with their own
+  label (`above % of the range`). A measurement whose signal is not acquired, or
   a window with too few crossings, must read `invalid`/`--` rather than a made-up number
   (`frequency` on a window holding one edge is the case: `duty` is reported only when a
   period exists to divide by). The probe then **walks the dialog's lifecycle**: open the edit
@@ -1040,6 +1050,70 @@ phase=2 … n=0 mean=0 sd=0 lo=0 hi=0   (all four)
 - `phase=2` — after Reset. **`n` must be 0 or 1** (0 if the report ran before the next recompute,
   1 if after); anything larger means Reset cleared nothing.
 
+## `[bandavg-probe]`
+
+`UDPSCOPE_PROBE_BANDAVG_MS`. Needs `UDPSCOPE_ENABLE_ALL_MS` ahead of it, and it must **not** be
+scheduled with `UDPSCOPE_PROBE_MEASURE_MS` or `UDPSCOPE_PROBE_MEASURES_MS`: all three add
+measurements to the same pane, and the later one would report the earlier one's rows as its own.
+Run it against the fast mock (`--rate 1300000 --batch 1000 --freq 1`) **at a 2 s window** — the
+figures below are shares of the range, and a window that holds a fifth of a cycle is a different
+question, not a worse answer. Its own sequence is about 12 s, so `UDPSCOPE_EXIT_AFTER_MS=17000`.
+
+It adds seven measurements, one per shape whose band mean can be computed by hand, and every one of
+them is a *mean over a side or a band* rather than a level. `--square-harmonics 30` and
+`--square-harmonics 0` are two runs — the second is the ideal step, where the band holds nothing:
+
+| measurement | shape | reading | why that shape |
+|---|---|---|---|
+| `above 50` | 1 Hz unit sine | `0.636620` | 2/pi, the figure the old `top` documented |
+| `below 50` | 1 Hz unit sine | `-0.636620` | its other side: exactly `-above 50` |
+| `between 50/75` | 1 Hz unit sine | `0.255873` | `3(2-sqrt 3)/pi`, and neither 0 (the window's mean) nor 0.5 (the band's edge) |
+| `above 50` | `square`, 30 harmonics / `0` | `0.986496` / `1.000000` | the reading that commit recorded as the *old* `top`; the ideal step has no ring to put inside it |
+| `between 50/75` | `square`, 30 harmonics / `0` | `0.302744` / `--` | the two edges' transitions the band holds; **every** sample is exactly +/-1 on the ideal step, so it holds nothing |
+| `between 50/75` | `ramp` | `0.250000` | uniform density: a band's mean *is* that band's centre |
+| `above 100` | `ramp` | `--` | a share at the top of the range has no sample above it |
+
+Four line kinds, and the reading is the third:
+
+```
+[bandavg-probe] waiting         stored=2108000 of 2600000 slots for a 2.000 s window
+[bandavg-probe] readings        window channel=0 lo=-1.000000 hi=1.000000 samples=2600000 levels=2
+[bandavg-probe] readings        above   'sine' shares=50%       -> ok       0.636620262 text=[636.62 mV]
+[bandavg-probe] edit opened     band_row=1 shares=50.0/75.0 (as stored)
+[bandavg-probe] after delete    measures=6 -> 5 (want one fewer)
+```
+
+- `waiting` — the probe reads nothing until the ring holds a **full window**: a share of a *partial*
+  window is a different number (and one that keeps moving while the ring fills), and the mock
+  delivers about 0.5 MS/s of the 1.3 MS/s it declares, so a ring the probe has just re-enabled needs
+  seconds of wall clock before a 2 s window is there. The wait is read off the store
+  (`stored_slots()` against `window / dt`), not guessed from a stopwatch. **A report taken before it
+  finishes is the one reading this probe can produce that is not the share's** — the settled lines
+  are the ones to quote.
+- `window` — the window each reading was taken over, per channel: `lo`/`hi` are that window's own
+  extremes (so `lo`/`hi` of the split are visible here), `samples` is what it holds, and `levels`
+  is how many level accumulators the pane registered for that channel. **`between` on the sine makes
+  `levels=2` where `top`/`between` alone would make one**: a band is two entries of the level list,
+  and a second measurement of the same band does not add a third.
+- the value line — the pane's own numbers, nine significant digits and then the row's formatted text
+  (`text=`), with the shares it was given. `-> invalid` with `text=[--]` is the nothing-to-measure
+  reading (the last two rows of the table). The value carries the measurement's **unit**; the three
+  new types are signal-valued like `top`/`average`, so a sine reads `mV` and a quantity with no unit
+  reads the bare number.
+- `edit opened` — the dialog's second-share row for a `between`: **`band_row` must be 1** (only
+  `between` offers it) and `shares` must be the pair that was *stored*, read back out of the two
+  spin fields. The probe then sets them to `50/90` and saves, and the next report is the proof the
+  field is wired: the sine's `between` reads `0.431361697` (`0.8 / (2 asin 0.8)`), where neither of
+  its sides would.
+- `after delete` — the cycle's last leg through the same dialog: **one fewer** measurement, process
+  alive. The two shares are the thing a delete could drop on the floor.
+- The `[measure-trace]` line the probe starts carries the same five readings every 250 ms, which is
+  where the *sixth* decimal's spread is visible (see the band-average invariant in
+  [invariants-measurements.md](invariants-measurements.md)): `above 50` on the sine reads
+  `0.636620` on almost every line and `0.636621` on a few, `above 50` on the square `0.986496` on
+  most and `0.986495` on the rest. **A line's `--` on a *lagging* trace is the trace's, not the
+  reading's** — the pane is refreshed on a cadence, so quote an earlier line beside its own `view=`.
+
 ## `[search-probe]`
 
 `UDPSCOPE_PROBE_SEARCH_MS`. The handler calls `condition_probe()` directly — the condition is