test: the per-second engine line shows the store's retained span, which pins a stalled clock

Diagnosing "going live from an event view does nothing for ~5 s, with the status bar green" needed a
distinction the engine's own fields cannot make. `n` counts every stored sample, so it climbs whenever data
arrives at all; what says *why* nothing moves is the store's stamp pair beside it. So the line gains
`ring=[oldest..newest] n=`:

    trig engine: … history=0.0000/0.4000 s … now_t=2.520 holdoff_until=2.520 ring=[2.5200..2.5200] n=567000
    trig engine: …                                       ring=[2.5200..2.5200] n=1131000
    trig engine: …                                       ring=[2.5200..2.5200] n=1689000

Three seconds apart, after `<live>`: the sample count climbs at the stream's rate (the data *is* arriving and
being stored) while the retained span is a single value — the file view's last stamp. So the producer's clock
is **frozen** after the restart, not lagging, which is why `history` never fills, why an armed trigger never
latches, and why a live view with the trigger off does not advance either: one cause, two faces, and it is
not the trigger.

The reading is what tells that apart from a stalled *feed* (ring moving, `now_t` still), which is a different
bug with a different fix — and neither is visible from `now_t` alone. `n` climbing beside a still `ring` is
the clock; a moving `ring` beside a still `now_t` is the feed.

The fix itself is the next piece of work: the producer's clock has to advance across a client restart (or the
file view's retained history has to go when going live), and this pair is the assertion it must satisfy —
after `<live>`, `ring` must move within a stream round-trip. Verified: `make test-ui` 14 files; the fields
observed in the transition run above; no `Gtk-CRITICAL`.

src/acquisition.cpp

@@ -917,12 +917,20 @@ void Acquisition::on_data(const udps_frame_t* frame) {
     std::fprintf(stderr,
                  "[udpscope] trig engine: ch=%d armed=%d pending=%d elapsed=%.4f/%.4f s "
                  "accum=%llu history=%.4f/%.4f s pre_pct=%.0f v=%.4g now_t=%.3f "
-                 "holdoff_until=%.3f\n",
+                 "holdoff_until=%.3f ring=[%.4f..%.4f] n=%zu\n",
                  trig_channel, int(engine.armed()), int(engine.pending()),
                  engine.post_elapsed(), engine.post_seconds(),
                  static_cast<unsigned long long>(engine.post_accum()), engine.history(),
                  engine.pre_seconds(), tc.pretrigger_pct, engine.last_value(),
-                 engine.last_t(), engine.holdoff_until());
+                 engine.last_t(), engine.holdoff_until(),
+                 // The store's own retained span, beside the engine's view of the clock. Going live
+                 // restarts the client, and the question a stalled display raises is whether the *time
+                 // ring* is moving at all: `n` climbing while `ring` stands still is a clock problem, and
+                 // `ring` moving while `now_t` does not is a feed problem. Neither can be told from the
+                 // engine's own fields.
+                 store.time().size() > 0 ? double(store.time()[0]) : 0.0,
+                 store.time().size() > 0 ? double(store.time()[store.time().size() - 1]) : 0.0,
+                 store.time().size());
     std::fflush(stderr);
   }
 }