fix(protocol): correct continuous-mode record header classification for accurate timestamp extraction

CHANGELOG.md

@@ -4,6 +4,27 @@ All notable changes to seismo-relay are documented here.
 
 ---
 
+## v0.13.1 — 2026-05-01
+
+### Fixed
+
+- **`_extract_record_type` — Continuous-mode record headers misclassified as Unknown.**
+  In single-shot mode the 0C waveform record's 9-byte header puts the sub_code
+  marker `0x10` at byte 1, with the day at byte 0.  In Continuous mode the
+  header is 10 bytes with the marker at byte 0 *and* byte 2, and the day at
+  byte 1.  Previous logic only inspected byte 1 and treated any value other
+  than `0x10` / `0x03` as `"Unknown"`, which prevented `event.timestamp` from
+  being populated for any continuous-mode event whose day-of-month wasn't
+  exactly 3 or 16.  As a downstream effect, `blastware_filename()` saw
+  `event.timestamp == None`, fell back to `stem="0000"` / `ab="00"`, and
+  produced filenames like `M5290000.000`.  Discovered from a live SFM run on
+  BE11529 in continuous mode (day-of-month = 5).
+  Now disambiguates by checking BOTH byte 0 and byte 2: if both are `0x10`,
+  it's the 10-byte continuous header; else if byte 1 is `0x10`, it's the
+  9-byte single-shot header.  Day-of-month no longer matters.
+
+---
+
 ## v0.13.0 — 2026-05-01
 
 ### Fixed