docs: cite the documented all-zero key B instead of inferring it

The previous round stated the key B premise as an inference and closed the
paragraph with "No key B is published, derived, or claimed anywhere in the
guide." That sentence is false. BambuLabRfid.md line 70 documents the sector
trailer as

  | 10 (BB) | 6 | RAW Bin | B-Key (always `00 00 00 00 00 00` for Bambu tags) |

and the guide's examples/exampleDump.bin carries six zero bytes at offset 10 of
all 16 trailers. This strengthens the change rather than weakening it: the
derived key A is a non-zero HKDF output, so it is definitively not the tag's key
B, and the 80 -> 16 arithmetic is established rather than conditional.

Lead the code comment with the two reasons that do not depend on what upstream
happens to publish: the tag's key B is all zeros so no derived key can match it,
and key A alone reads every block this plugin parses so any key B entry is waste
regardless. The old wording led with the absence of a published key B
derivation, which a reader who later finds BambuLabRfid.md could take as
refuted and use to justify restoring the key B assignment.

Drop the CHANGELOG's "were a tag's key B in fact equal to its key A" hedge for
the same reason. "Publishes that derivation alone" is narrower and stays.

No behaviour change: .text 3,364, .rodata 7,596, .fal 21,548 and the 18-symbol
import list are identical before and after.

Author: uzyn

CHANGELOG.md

@@ -46,15 +46,14 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
   [RFID-Tag-Guide](https://github.com/Bambu-Research-Group/RFID-Tag-Guide)
   publishes that derivation alone, describing what it recovers as "all required
   A-Keys" — and key A on its own reads every block this plugin parses, so the
-  key B entries could not unlock anything key A could not. Taking the upstream
-  evidence at face value, the tag's real key B differs from the derived key A,
-  each of those 16 offers failed, and because a failed authentication halts the
-  tag the poller retried each one once per block in the sector: 64 failed
-  authentications and 64 card re-selections per scan, so the read path drops
-  from 80 authentications to 16. Were a tag's key B in fact equal to its key A,
-  the drop would instead be 32 to 16 with no failures involved. The read is
-  strictly cheaper either way and the parsed result is unchanged.
-  ([#3](https://github.com/uzyn/flipper-bambu/issues/3))
+  key B entries could not unlock anything key A could not. That guide's
+  `BambuLabRfid.md` also documents the trailer's key B as "always
+  `00 00 00 00 00 00` for Bambu tags", which the non-zero derived key never
+  matches, so each of those 16 offers failed; and because a failed
+  authentication halts the tag, the poller retried each one once per block in
+  the sector: 64 failed authentications and 64 card re-selections per scan, so
+  the read path drops from 80 authentications to 16. The parsed result is
+  unchanged. ([#3](https://github.com/uzyn/flipper-bambu/issues/3))
 
 ## [1.1.0] - 2026-05-13
 

plugin/bambu.c

@@ -267,10 +267,11 @@ static void bambu_derive_keys_from_uid(const uint8_t* uid, size_t uid_len, MfCla
         generated += chunk_len;
     }
 
-    // Key A only — do not restore the key B assignment. The HKDF context is
-    // "RFID-A" and upstream publishes no key B derivation, and the trailers'
-    // 87 87 87 access bits leave every block this plugin parses readable with
-    // key A, so key B entries buy nothing and cost an auth attempt per block.
+    // Key A only — do not restore the key B assignment. Bambu tags carry an
+    // all-zero key B (RFID-Tag-Guide, BambuLabRfid.md), so no derived key can
+    // match it; and the trailers' 87 87 87 access bits leave every block this
+    // plugin parses readable with key A, so any key B entry — derived, guessed
+    // or known — buys nothing and costs an auth attempt per block.
     for(size_t sector = 0; sector < sector_count; sector++) {
         const uint8_t* sector_key = &key_material[sector * key_size];
         memcpy(keys->key_a[sector].data, sector_key, key_size);