fix: a paused view carries its own LOD pyramid, so it is drawn like a held event

publish_pause_view() filled stamps, values and y and left pyramids empty, so
level_for() descended to raw samples and a frozen pause was re-gathered from
every sample it held on every frame. It cost draw time (12.34 -> 18.18 ms mean)
and, because stage_trace_density() normalises each column against its own peak,
it also changed how the trace looked -- which is how it was noticed.

Both publishes are now timed and reported as `publish cost:`, counted apart
because they stall opposite threads: the event publish runs on the producer
under mutex() and blocks the UI, the pause publish runs on the UI thread and
blocks the producer. That is the number a second live ring has to be judged
against.

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

README.md

@@ -459,7 +459,8 @@ ring per channel (N enabled signals -- see the limitation on multi-element signa
 below). The spec's second buffer is the latched `EventSnapshot`, which is already
 an immutable copy of the captured window (see "Trigger" below); a second live ring
 bought nothing and cost half the memory budget, so `--buffer-mb 200` really is
-200 MB.
+200 MB. What it *would* buy is priced in the dump's `publish cost:` line — see
+"There is one live buffer, not two" under the review findings.
 `plan_partition()` sizes the rings to cover `--max-window` seconds and then grows
 them with the rest of the budget. When a channel's declared sample rate is lower
 than the fastest channel's, it is decimated by the integer ratio
@@ -973,8 +974,31 @@ which hides exactly the spike a capture was triggered on, and since the level wa
 it never even ran. On the same repro: **138,078 segments** (43× fewer) and a 66 ms worst
 frame, with the steady-state draw around 2 ms. It costs about 1 byte per sample per
 channel (≈25 % on top of the snapshot's `f32` values) and one stall per latch, since the
-build runs under `ScopeModel::mutex()` — at 1.3 MS/s that is a ~40 ms tick, once, with no
-packet gaps.
+build runs under `ScopeModel::mutex()`. That stall is now measured rather than estimated —
+the dump's `publish cost:` line read **115 ms** for one event publish at 1.3 MS/s, against
+the ~40 ms this paragraph used to quote — and it produced no packet gaps.
+
+**A paused view carries one too**, and that half was missing until it was found by its
+*appearance*. `publish_pause_view()` filled `stamps`, `values` and `y` and left `pyramids`
+empty, so a frozen pause was drawn from every raw sample it held, on every frame — the same
+defect as above with the same cause, in the other snapshot. `frame path:` read
+`raw=21 lod=118` over a 1.6 s pause against `raw=1 lod=170` for the same run live, with the
+draw mean going 12.34 → 18.18 ms and its worst frame 30.35 → 86.92 ms. But the reason it was
+noticed is that the trace *looked* different: `Renderer::stage_trace_density()` grades each
+pixel column against that column's own peak, from a `1/height` dwell deposit per segment, so
+a column fed several hundred raw inter-sample segments accumulates a far spikier
+distribution — and a far larger peak to normalise against — than one fed the one or two
+bucket envelopes the pyramid gives. The paused trace read as a hard bright core with its
+dwell tail dimmed away. The rule the invariant was written without: **a pause is not a
+cheaper case than a capture — it freezes the same rings.**
+
+It is not free, and the trade is one-off against per-frame. Building the pause pyramid took
+that publish from 6.15 ms to 22.31 ms, and unlike the event publish this one runs on the
+**UI** thread and so blocks the *producer* — against ~5 ms a frame of draw for as long as the
+pause lasts, which over a 1.6 s pause at ~60 fps repays thirty times over. One finding there
+is still open: a run that pauses reports `gaps=73` where the same run without a pause reads
+`gaps=0`, and it does **not** scale with the publish length (79 gaps with the pyramid build
+removed, 73 with it), so the stall is not what it is.
 
 The self-check's two `frame cost:` / `frame path:` lines are the guard: they split a frame
 into the tick, the plot's own draw and the whole GTK paint, and report the segment counts
@@ -1738,7 +1762,17 @@ now — they are listed so they are not mistaken for anything else:
   latched `EventSnapshot` — an immutable copy of the captured window, which is
   exactly what "the buffer the view is frozen on" needs to be. Two live rings would
   also mean acquisition had to follow the trigger state, which is what left the first
-  latch after arming with no pre-trigger history.
+  latch after arming with no pre-trigger history. What a second ring would buy is the
+  publish: freezing a whole `BufferStore` copies nothing and inherits the pyramid the
+  producer already maintains, so both figures in the dump's `publish cost:` line would
+  go to zero. They are worth knowing before pricing that — one event publish measured
+  **115 ms of blocked UI tick** at 1.3 MS/s and one pause publish **22 ms of blocked
+  producer** — but they do not pay for a second budget's worth of memory, a second
+  per-sample write on the producer, and a single frozen slot where the app today holds
+  an event, a pause and an export's window at once. One thing to settle first: a run
+  that pauses reports `gaps=73` against `gaps=0` without a pause, and that does not
+  scale with the publish length, so it is not the stall and a second ring would not
+  obviously fix it.
 - **The buffer is allocated at the first CONFIG, not at initialisation.**
   The spec's "N+1 split" needs N, which only a CONFIG gives; `--buffer-mb` is the
   *budget*, and the power-of-two ring rounding means the final