fix: redefines rectime_seconds from strt[18] byte to new computed time.

The server now re-computes rectime_seconds using the actual sample rate from the compliance config (overriding the default 1024 in the client), so if the device runs at 2048 or 4096 sps it's still correct.

Viewer — The rectime display now shows Xs (stored) / Ys (cfg) so you can compare the STRT-derived duration against the compliance config's record_time setting side-by-side. I also clamped the y-axis to ±(0C peak × 1.4) so near-saturation decode artifacts don't squash the real blast signal into a flat line.

sfm/server.py

@@ -689,13 +689,22 @@ def device_event_waveform(
     if sample_rate is None and info.compliance_config:
         sample_rate = info.compliance_config.sample_rate
 
+    # Recompute rectime_seconds using the actual sample rate now that we have it.
+    # _decode_a5_waveform used 1024 sps as default; override if device says otherwise.
+    # strt[18] is a record-mode byte (0x46 / 0x0E), NOT rectime in seconds.
+    rectime_seconds = ev.rectime_seconds
+    if (ev.total_samples is not None and ev.pretrig_samples is not None
+            and sample_rate and sample_rate > 0):
+        post_trig = max(0, ev.total_samples - ev.pretrig_samples)
+        rectime_seconds = round(post_trig / sample_rate, 2)
+
     result = {
         "index":           ev.index,
         "record_type":     ev.record_type,
         "timestamp":       _serialise_timestamp(ev.timestamp),
         "total_samples":   ev.total_samples,
         "pretrig_samples": ev.pretrig_samples,
-        "rectime_seconds": ev.rectime_seconds,
+        "rectime_seconds": rectime_seconds,
         "samples_decoded": samples_decoded,
         "sample_rate":     sample_rate,
         "peak_values":     _serialise_peak_values(ev.peak_values),