fix(protocol): add record_time based chunk scaling for longer event record times

docs/instantel_protocol_reference.md

@@ -1248,9 +1248,25 @@ Two critical differences from `build_bw_frame`:
 > for all keys encountered on this device.
 
 The `stop_after_metadata=True` flag causes the loop to stop as soon as `b"Project:"` is
-found in the accumulated A5 frame data, typically after 7–9 chunks.  A termination frame
+found in the accumulated A5 frame data, typically after 4–9 chunks.  A termination frame
 is always sent before returning.
 
+**IMPORTANT — one extra chunk required after "Project:" for valid file footer (confirmed 2026-04-23):**
+When writing a Blastware-compatible waveform file, stopping immediately at "Project:" and
+sending termination produces an empty termination response with no footer bytes (`0e 08`
+marker missing).  Blastware downloads exactly **one more chunk** after finding "Project:"
+before sending termination — that extra chunk primes the device to return valid footer
+bytes (monitoring start/stop timestamps) in the termination response.
+
+`read_bulk_waveform_stream(stop_after_metadata=True)` implements this: after the "Project:"
+chunk is received, one additional chunk is requested before breaking.  The termination
+response (`include_terminator=True`) then contains the correct `0e 08` footer.
+
+**do NOT use `full_waveform=True` for Blastware file writing** — for events with long
+post-event silence (35 chunks), the silence chunks contain embedded device-internal
+pointer structures that produce spurious STRT markers in the file body.  Blastware only
+downloads 4–5 chunks (metadata + one signal chunk) regardless of event length.
+
 #### 7.8.3 A5 Frame Layout
 
 Each A5 response frame contains a chunk of raw bulk data. Frame 7 of the stream carries the