fix: update MiniMateClient and protocol to ensure correct handling of 1F calls and improve event download sequence

CLAUDE.md

@@ -205,12 +205,23 @@ POLL × 3
 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.
+**IMPORTANT — conditional browse 1F (UPDATED 2026-04-06):**
+`1F(token=0xFE)` (browse=False) BEFORE POLL+5A arms the device's bulk stream state machine.
+Its returned key is cached as `arm_key4` in `get_events()`.
+
+`1F(browse=True)` AFTER 5A is ONLY sent when 5A **succeeded**.  If 5A timed out or failed,
+sending browse 1F disrupts the device's internal state — subsequent 5A probes for the next
+event get no response (confirmed empirically: calling browse 1F after a failed 5A causes the
+next event's 5A probe to also time out with 0 bytes received).
+
+In the failure path, `arm_key4` from `1F(download)` is used as a best-effort next-key hint:
+- If `arm_key4 != cur_key`: use it to advance the loop without any 1F call
+- If `arm_key4 == cur_key` (device stuck, typical for second+ events when 5A fails): abort
+
+The diagnostic `bytes_fed` counter on `S3FrameParser` (incremented in every `feed()` call,
+reset by `reset()`) makes it possible to distinguish "no bytes at all" from "bytes received
+but no complete frame assembled" in 5A probe timeouts — both show up as 120s timeouts in
+the log but have very different root causes.
 
 **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