feat: update s3_bridge to v0.4.0 with annotation markers and dual log output

docs/instantel_protocol_reference.md

@@ -30,6 +30,7 @@
 | 2026-02-26 | §15 → Appendix A | **RENAMED:** Binary log format section moved to Appendix A with explicit note that it describes tooling behavior, not protocol. |
 | 2026-02-26 | Header | **ADDED:** Certainty legend clarification — ratings apply to protocol semantics only, not tooling behavior. |
 | 2026-02-26 | §7.6 Channel Config Float Layout | **NEW SECTION:** Trigger level confirmed as IEEE 754 BE float in in/s. Alarm level identified as adjacent float = 1.0 in/s. Unit string `"in./s"` embedded inline. `0x082A` removed as trigger level candidate. |
+| 2026-02-25 | Appendix A | **UPDATED:** v0.4.0 — annotation markers added. `.bin` sentinel format documented. Parser caveat added for SUB `5A` raw ADC payloads. |
 
 ---
 
@@ -631,7 +632,7 @@ Build in this order — each step is independently testable:
 | Channels | Tran, Vert, Long, MicL (4 channels) |
 | Sample Rate | ~1024 sps (🔶 INFERRED) |
 | Bridge Config | COM5 (Blastware) ↔ COM4 (Device), 38400 baud |
-| Capture Tool | s3_bridge v0.4.0 |
+| Capture Tool | s3_bridge v0.4.0 (annotation markers, dual .log/.bin output) |
 
 ---
 
@@ -639,10 +640,13 @@ Build in this order — each step is independently testable:
 
 ## Appendix A — s3_bridge Capture Format
 > ✅ **CONFIRMED — 2026-02-26**
+> ⚠️ **Updated for v0.4.0 — annotation markers added.**
 
 > ⚠️ **This behavior is not part of the Instantel protocol. It is an artifact of the bridge logger implementation.**
 
-The `.bin` files produced by `s3_bridge` are **not raw wire bytes**. The logger makes one modification:
+### A.1 Binary modifications
+
+The `.bin` files produced by `s3_bridge` are **not raw wire bytes**. The logger makes one modification to frame data:
 
 | Wire sequence | In .bin file | Notes |
 |---|---|---|
@@ -656,6 +660,33 @@ The `.bin` files produced by `s3_bridge` are **not raw wire bytes**. The logger
 
 > ⚠️ This means checksums cannot be verified on frames where the stuffed payload ends in `0x10` — that trailing `0x10` would normally be the DLE prefix of ETX, but the logger strips it, making the frame boundary ambiguous in that edge case. In practice this has not been observed in captured data.
 
+### A.2 Annotation markers (v0.4.0+)
+
+When the operator types `m` + Enter during a capture, both files receive a marker at that timestamp.
+
+**`.log` format:**
+```
+[HH:MM:SS.mmm] >>> MARK: label text here
+```
+The `>>>` prefix never appears in frame log lines (which use `[direction]`) and is trivially skippable by a parser.
+
+**`.bin` format — out-of-band sentinel:**
+```
+FF FF FF FF <len: 1 byte> <label: len bytes, UTF-8>
+```
+
+The four `0xFF` sentinel bytes are chosen because `0xFF` is not a valid byte in any Instantel framing position:
+- Not a valid ACK (`0x41`), DLE (`0x10`), STX (`0x02`), or ETX (`0x03`)
+- The `0xFF - SUB` response pattern produces values like `0xA4`, `0xEA`, `0xFE` — never a bare `0xFF` in the framing layer
+
+**⚠️ Parser caveat — SUB `5A` raw ADC payloads:**
+The sentinel assumption is robust for the framing layer, but the raw ADC sample data in SUB `5A` bulk waveform streams is less constrained. High-amplitude samples could theoretically produce `FF FF FF FF` within the data portion of a frame. **Do not scan the entire `.bin` file as a flat byte stream for sentinels.** Instead:
+1. Parse frame boundaries first (walk `0x41` ACK → `0x10 0x02` STX → ... → bare `0x03` ETX)
+2. Only scan for `FF FF FF FF` in the **gaps between frames** — sentinels are always written between complete frames, never mid-frame
+3. Any `FF FF FF FF` appearing inside a frame boundary is ADC data, not a marker
+
+Session start and end are automatically marked in both files.
+
 ---
 
 ## 14. Open Questions / Still Needs Cracking