disc: credit firmware unlock in the bus-encryption gate

The bus-key gate only credited the cert handshake's read_data_key as proof
bus encryption was removed. A firmware unlocker removes it AT THE DRIVE
(serves clear content) and yields no read_data_key — so a SUCCESSFUL
firmware unlock (VID present, read_data_key None) tripped the gate and
blocked ALL key resolution, including the online source. That was the
root cause of live UHD discs reporting "missing keys" after an unlock.

Now a single predicate answers "is bus encryption gone?": never-had-it ||
file/ISO || firmware-unlocked || cert-bus-key. The gate is just
`if !bus_encryption_removed { error }` — no enumerated cases. HandshakeResult
gains `drive_unlocked`, and the read_data_key failure reason is captured so
the warn says WHY the bus key is missing.

Also: reword the first hardware-sense escalation as "fast-fail escalation"
(it is often transient — the drive recovers), reserving "wedge" for a
persistent run; and scrub the product name from core comments (it belongs
only in the unlocker crate).

src/aacs/trace.rs

@@ -31,7 +31,7 @@ impl ResolutionTrace {
 // ── Unlock phase ────────────────────────────────────────────────────────────
 
 /// One unlocker's contribution to the unlock phase. `who` is the unlocker's
-/// `name()` (a stable identifier, e.g. `"LibreDrive"`), carried verbatim.
+/// `name()` (a stable, product-neutral identifier), carried verbatim.
 #[derive(Debug, Clone, PartialEq)]
 pub struct UnlockStep {
     pub who: String,