fix: add new helper (_recv_5a_batch()) that helps with assembling chunks over TCP

CLAUDE.md

@@ -347,6 +347,24 @@ Do NOT use fixed absolute offsets for sample_rate or record_time.
   Quiet Mode enabled. Parser handles this — do not strip it manually before feeding to
   `S3FrameParser`.
 
+**SUB 5A (bulk waveform) TCP frame splitting — confirmed 2026-04-27:**
+
+Over TCP via cellular modem, each 5A chunk request that produces a single ~1100-byte
+A5 response over direct RS-232 arrives as **two separate, complete S3 frames** of
+~550 bytes each.  This is because the device sends its RS-232 response as multiple
+frames, and the modem's Data Forwarding Timeout (~100-150 ms) delivers them to us
+as separate TCP segments, each parsed as a complete S3 frame.
+
+Example for a 2-second Continuous event (BE11529, key=01110000) via TCP:
+- 1 probe frame (554 B) + 5 chunks × 2 frames (556-573 B) + 1 extra chunk × 2 frames + 1 terminator (208 B) = **14 A5 frames**
+- All 14 frames contribute body data; using all of them gives the correct 6864-byte file.
+
+**Fix (confirmed 2026-04-27):**  `_recv_5a_batch()` in `protocol.py` collects ALL
+A5 frames per chunk request before the next request is sent, using a 0.5 s batch
+timeout after the first frame to catch the ~150 ms delayed second frame.  `write_blastware_file()`
+includes ALL body frames without skipping — the extra chunk's frames are part of the
+body data, NOT padding to be discarded.
+
 ### Required ACEmanager settings (Sierra Wireless RV50/RV55)
 
 | Setting | Value | Why |