docs: a pause publish costs no packets, and the look is checked with frame path

An A/B of the same fast-mock run with and without a pause reads gaps=0 both
ways, the paused one having published in 86 ms -- so the gaps=73 recorded
yesterday as "a pause costs packet gaps, unexplained" was incidental load on
one run. It never scaled with the publish length and has not reproduced.

Record the publish figures as the range they actually span across runs
(event 69-115 ms, pause 22-86 ms) rather than as single readings, and name
`frame path:` across a pause as the check that the paused trace is drawn like
a live one -- raw=1 lod=555 against raw=0 lod=373, where the defect read
raw=21 lod=118.

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

CLAUDE.md

@@ -726,20 +726,22 @@ Two lines of the self-check output are assertions in disguise:
   `publish_event()` runs on the producer with `mutex()` already held, so its cost lands on the UI
   as a long tick; `publish_pause_view()` runs on the UI thread and takes the lock, so its cost
   lands on the producer and can only surface as `gaps`. Read the event figure against `tick`'s max
-  and the pause figure against `gaps`. Measured on the fast mock over a 3 s run: one event at
-  **115 ms** and one pause at **22.3 ms** — the event figure is far above the ~40 ms the `tick`
-  entry above quotes, so treat that 40 as the old reading and this line as the authority.
+  and the pause figure against `gaps`. Both are **wide**: on the fast mock the event publish has
+  read **69, 89, 92 and 115 ms** and the pause publish **22 and 86 ms** across runs, so treat the
+  line as an order of magnitude and not a figure to compare a change against at the millisecond.
+  The event reading matters anyway because it is far above the ~40 ms the `frame cost:` entry above
+  quotes — treat that 40 as the old reading and this line as the authority.
   It is also **the number to judge a second live ring against**, which is the one design question
   it exists to answer: freezing a whole `BufferStore` copies nothing and inherits the pyramid a
   `ChannelBuffer` already maintains incrementally, so both `worst` figures would go to **0** — at
   the price of a second budget's worth of memory (README records that one live ring is why
-  `--buffer-mb 200` really is 200 MB) and a second per-sample write on the producer. Two things
-  make the trade less obvious than the memory arithmetic suggests, and both were measured rather
-  than reasoned: the event publish really is ~115 ms of blocked UI, and **a pause costs `gaps`
-  where a run without one reads `gaps=0`** (73 with the pause against 0 without). That second
-  finding is *not* the publish length — it read 79 gaps with the pyramid build removed and 73 with
-  it, i.e. it does not scale with the stall — so it is **unexplained**, and anyone pricing a second
-  ring should find out what it actually is first rather than assume the ring would fix it.
+  `--buffer-mb 200` really is 200 MB) and a second per-sample write on the producer. What the line
+  says about that trade is that the stall is real but **costs no packets**: an A/B of the same run
+  with and without a pause read `gaps=0` both ways, the paused one with an 86 ms publish, so a
+  second ring would buy a smoother frame at a latch rather than recovered data. (An earlier run
+  reported `gaps=73` with a pause against 0 without, which is what made the stall worth measuring;
+  it has not reproduced and did not scale with the publish length — 79 gaps with the pyramid build
+  removed against 73 with it — so it was incidental load on one run. Do not quote it as a cost.)
 - `trace ink: N paints checked, C collapsed, S staircase, H short, worst cover P%, worst
   drawn-vs-quoted D px over R raw paints` plus a
   `[ink] paint N <flags> mode=.. axis=[..] n=.. idx=[..) spp=.. level=.. pts=.. kept=..
@@ -1173,7 +1175,13 @@ far the largest file.
   anything `publish_event()` does to a snapshot, `publish_pause_view()` owes too. Building it is
   not free (see `publish cost:` below): it took the pause publish from 6.15 ms to 22.31 ms, a
   one-off producer stall against ~5 ms a frame of draw for the pause's whole length, which at
-  ~60 fps repays about thirty times over on a 1.6 s pause.
+  ~60 fps repays about thirty times over on a 1.6 s pause — and the producer absorbs it without
+  losing packets (`gaps=0` with and without a pause, the paused run at an 86 ms publish).
+  **The check that the look is restored is `frame path:` across the pause, not the cost line**:
+  a paused run must read the same path as a live one — measured `raw=1 lod=555 columns=555
+  graded=555` against `raw=0 lod=373 columns=373 graded=373`, same 24711-segment worst frame,
+  segment mean within 5 % — where the defect read `raw=21 lod=118`. A `raw` in the tens over a
+  pause is this returning, and it is the appearance as much as the cost.
 - **`EventSeries::gather()` emits a bucket's envelope, not every `2^level`-th sample.**
   Point decimation hides exactly the spike the capture was triggered on; a scope has to
   draw a bucket's extremes. It needs no index rebasing, unlike the ring: the snapshot's