fix: update MiniMateClient to correctly handle 1F calls for event iteration and 5A arming

CLAUDE.md

@@ -192,18 +192,26 @@ there is only one event.
 0A(key0)                                ← REQUIRED: establishes device context
 1E(token=0xFE)                          ← REQUIRED: arms device for 5A; CONFIRMED 4-2-26 + 4-3-26
 0C(key0)                                ← read waveform record
-1F(all zeros / browse=False) → key1     ← MUST come BEFORE 5A (BW sequence, confirmed 4-2-26)
+1F(token=0xFE) → [discard key]          ← REQUIRED: arms 5A bulk stream state machine
 POLL × 3                                ← REQUIRED: 3 full POLL cycles before 5A (BW frames 68-73)
 5A(key0)                                ← bulk stream; key0 used even though 1F already advanced
+1F(all zeros / browse=True) → key1      ← USE THIS for loop iteration (browse=True returns correct key)
 0A(key1)
 1E(token=0xFE)                          ← re-arm for next event's 5A
 0C(key1)
-1F(browse=False) → key2
+1F(token=0xFE) → [discard key]          ← arm 5A
 POLL × 3
 5A(key1)
-1F(browse=False) → null                 ← done
+1F(browse=True) → null                  ← done
 ```
 
+**IMPORTANT — two separate 1F calls per event (CONFIRMED 2026-04-06):**
+`1F(token=0xFE)` (browse=False) BEFORE POLL+5A arms the device's bulk stream state machine
+but returns inconsistent iteration keys after the first event — do NOT use its returned key
+for loop control.  `1F(browse=True)` AFTER 5A returns the correct next event key for
+iteration.  The reason is device-side: `1F(0xFE)` appears to arm 5A and peek the next key
+without reliably advancing the internal iteration pointer; `1F(all-zero)` advances it.
+
 **The 1E(token=0xFE) arm step is required (FIXED 2026-04-06):**
 The device silently ignores all 5A probe frames unless a second SUB 1E with token=0xFE
 has been issued between 0A and 0C.  This step is present in EVERY download cycle in both