fix: store the stream clock as f64, so a stamp's precision does not decay with uptime

The time ring was f32 like the values, holding each stamp relative to an epoch
fixed at the first sample ever seen -- so the number stored grew for as long as
the app ran while the interval it had to resolve stayed one sample period. At
1 MS/s the f32 ULP reaches the sample period after about sixteen seconds, so two
to four consecutive samples rounded onto one stamp after half a minute and eight
after a minute. On screen that is a plateau the LOD envelope draws as a
zero-width segment -- a vertical spike where the waveform should be -- and in an
export it was three distinct diffs at 2, 2.5 and 3 ULP instead of one clock.

A value's precision is a property of the signal; a timestamp's is a property of
how long the scope has been running. Only the clock widens: the values are the
memory budget. That makes the two slices different sizes per slot, so
plan_partition() weighs its growth loop in bytes rather than in slots (and
bytes_for() is what bounds the doubling); live_window_locked() loses the f32
round-trip of its bounds, which existed only to keep a sample sitting exactly on
one; and EventSnapshot::stamps is f64 because a pause view is not rebased and so
carries full stream time.

Verified against the fast mock: np.diff over two million exported rows now holds
exactly one step (1e-06, 1999999 times), no duplicate or backwards stamps, and
the 200 MB ring still spans 8.39 s. Every documented probe assertion unchanged.

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

CLAUDE.md

@@ -553,6 +553,11 @@ Two lines of the self-check output are assertions in disguise:
   README) and a per-sample step derived from the client's `lost` counter (now the
   stream's measured arrival cadence). A `rows=` count far below the span times the rate
   is the other signature, that of a table cut from the LOD pyramid.
+  **`set(np.diff(t))` must hold exactly one value**, and this is the check that needs a long
+  run at a high rate: a *plateau* of equal stamps, or a diff taking two or three values a few
+  hundred nanoseconds apart, is the time ring losing precision with uptime (see the `f64`
+  time-ring invariant below — the figure to compute is the ULP of `t[0]`, since the defect
+  grows with how long the app has run, not with the export's own length).
 - `badge frames: lit=L dim=D idle=I` — the activity badge's phase per frame. Over a run
   that acquired anything **both `lit` and `dim` must be non-zero**: that is what "it
   blinks" means, and a badge stuck lit is indistinguishable from a working one in a
@@ -898,6 +903,29 @@ far the largest file.
   draw a bucket's extremes. It needs no index rebasing, unlike the ring: the snapshot's
   pyramid is built from sample 0 and nothing is ever dropped from it, so `window_base()` is
   0 and a window index *is* the absolute one.
+- **The time ring is `f64` and the value rings are `f32`, and the asymmetry is the point.**
+  A value's precision is a property of the signal (24 bits is plenty for a sample); a
+  timestamp's is a property of *how long the scope has been running*, because the stamps are
+  stored relative to an epoch fixed at the first sample ever seen and so grow without bound
+  while the interval they must resolve stays one sample period. `f32`'s ULP is 1.9 µs at 16 s
+  of uptime, 3.8 µs at 32 s, 7.6 µs at 64 s and 61 µs over a 600 s window — so at 1 MS/s two
+  to four consecutive samples shared a stamp after half a minute, eight after a minute, and
+  the LOD envelope over such a plateau drew a zero-width segment, i.e. a vertical spike where
+  the waveform should be. That is "zoom in to ~10 µs and three to five points share a
+  timestamp, and min/max produces artefacts". **Do not widen the values to match**: they are
+  the memory budget, and nothing about them is magnitude-bound this way. Three consequences:
+  `plan_partition()` can no longer count slots in its growth loop (a time slot and a value
+  sample are different sizes, so it weighs the budget in **bytes** — `sizeof(f64)` for the
+  clock plus `sizeof(f32) / stride[i]` per channel — and `bytes_for()` is also what bounds
+  the doubling against overflow); `live_window_locked()` compares its bounds in the ring's own
+  type with **no rounding step**, the old `f32` round-trip having existed only so that a
+  sample sitting exactly on a bound was kept whatever the stream's absolute time was; and
+  `EventSnapshot::stamps` is `f64` because a **pause** view is deliberately *not* rebased and
+  therefore carries full stream time (an event's own stamps are edge-relative and small — the
+  symmetry is not the reason). `RingBuffer<T>` stores slots as `std::atomic<T>` behind a
+  `static_assert(is_always_lock_free)`, which `double` satisfies on every supported target.
+  The guard is the **export**: `np.diff(t)` over a multi-million-row `.npy` must hold exactly
+  one distinct step. Three steps at 2, 2.5 and 3 ULP of the stamps' magnitude is this defect.
 - **A dropped time slot is clamped, never answered with a sentinel.** `acquire()` pins
   the published window to the value ring's base and both rings keep sliding afterwards —
   their capacities are equal, so there is no slack — which means the oldest few samples