fix(protocol): correct A5 frame classification and chunk counter formula

CLAUDE.md

@@ -118,9 +118,11 @@ S3→BW (response):
 Both differences confirmed by reproducing Blastware's exact wire bytes from the 1-2-26
 BW TX capture. All 10 frames verified.
 
-### SUB 5A — chunk counter is monotonic (CORRECTED 2026-04-06)
+### SUB 5A — chunk counter formula (FINAL CORRECTION 2026-04-24)
 
-**Chunk counters are `chunk_num * 0x0400` for ALL chunks including chunk 1.**
+**Chunk counter = `key4[2:4] + (chunk_num - 1) * 0x0400` for ALL chunks.**
+
+where `key4[2:4] = (key4[2] << 8) | key4[3]` is the event's circular-buffer base offset.
 
 The 4-2-26 BW TX capture showed `counter=0x1004` for chunk 1 of event key `01110000`, which
 led to `_CHUNK1_COUNTER = 0x1004` being hardcoded as a special case. This was a Blastware
@@ -130,9 +132,14 @@ immediately and streams all frames correctly.
 
 The 4-3-26 capture confirms the pattern for a second event (key `0111245a`):
 chunk 1 = `0x245A`, chunk 2 = `0x285A`, chunk 3 = `0x2C5A` (each +0x0400). Blastware's
-true formula is `key4[2:4] + n * 0x0400` — but since `key4[2:4]` of the first event is
-`0x0000`, `n * 0x0400` produces the right result. The device does not strictly validate the
-counter and streams data for any valid 5A request; using `chunk_num * 0x0400` is correct.
+true formula is `key4[2:4] + (chunk_num - 1) * 0x0400`.
+
+**2026-04-24 CORRECTION — `n * 0x0400` is WRONG for non-first events.** For event key
+`01110000`, `key4[2:4] == 0x0000` so the old `chunk_num * 0x0400` formula was accidentally
+correct. For keys with `key4[2:4] != 0` (e.g. key `01111884`, offset `0x1884`), the old
+formula sends counters pointing into the wrong buffer region — the device returns data from
+a completely different stored event and `b"Project:"` never appears in the stream.
+Use `key4[2:4] + (chunk_num - 1) * 0x0400` exclusively.
 
 ### SUB 5A — params are 11 bytes for chunk frames, 10 for termination