Fix readable MIFARE Classic Key B handling

[oSPANNERo]

Summary

Fix MIFARE Classic recovery handling for sector trailers where Key B is readable as data instead of necessarily being usable as an authentication key.

The recovery flow now:

• decodes trailer access conditions before classifying readable Key B bytes
• verifies whether readable Key B bytes can actually perform memory access before marking them as a found key
• tracks readable-only Key B data separately from authentication keys
• treats readable Key B as a resolved state so recovery does not continue attacking it
• displays readable-only Key B data with a blue visibility icon and tooltip

The write flow now also:

• treats a found Key A plus a readable-only Key B as sufficient write readiness
• shares that readiness behavior between Gen2 and Gen3
• only attempts a recovered Key B write when the stored Key B is actually six bytes, while preserving the generic-Key-B fallback
• verifies an acknowledged Gen2/Gen3 sector-trailer write before treating that sector as clean or replacing the recovered keys
  • the expected Key A must successfully read the resulting trailer
  • access-condition bytes and GPB must match the requested trailer
  • readable Key B data is compared directly
  • protected Key B is verified by authentication
• briefly preserves the completed recovery state before transitioning to the write interface so readable/found key state remains visible

This also addresses the write-readiness behavior reported in #976, where readable Key B sectors could leave the Write action unavailable.

Validation

Validated with automated tests, synthetic fixtures, and physical/emulated hardware cases:

• Flutter tests: 22/22 pass
• focused Gen2 trailer-write regressions: 3/3 pass
  • acknowledged-but-unapplied trailer write is detected and the overall write reports failure
  • an applied trailer with readable Key B data verifies successfully
  • an applied trailer with protected Key B verifies successfully by authentication
• flutter analyze for the modified/relevant recovery, write, UI, and Gen2 regression-test files: no issues
• Windows release build: pass
• synthetic MIFARE Classic Key-B state-matrix regression: expected 16/16 sector state pattern
  • readable-only Key B sectors show blue/readable
  • unresolved Key A control leaves readable B unresolved
  • protected missing Key B control remains unresolved
• physical Gen2/CUID clone: readable B values that also work for memory access are correctly classified as found keys
• original physical source card: same usable-readable-B behavior correctly classified as found keys
• Gen2 write-readiness regression for Inability to record a card #976:
  • all Key A values found
  • protected odd-sector Key B values found
  • readable-only even-sector Key B values remain blue/readable
  • no unresolved sectors
  • Write action becomes enabled
• end-to-end Gen2 write test against a Proxmark3-emulated target:
  • target block 1 was changed to A5 x16 before the write
  • the GUI completed the normal write successfully
  • emulator memory verified block 1 changed back to 01 x16
  • the same test passed again on the amended branch
• false-success regression reproduced against a Proxmark3-emulated ACL-010 target before the safeguard:
  • source requested sector 0 trailer ACL/GPB FF 07 80 69
  • target retained protected trailer ACL/GPB 7F 0F 08 69
  • the Chameleon write command reported success for the trailer write
  • an ordinary data block was still modified
  • the GUI nevertheless reported the card write as successful
• the added trailer verification prevents that acknowledged-but-unapplied trailer write from being treated as a successful sector transition

This distinguishes readable trailer data from real authentication capability while still supporting compatible cards that accept the same readable bytes as Key B, and prevents the newly reachable write path from reporting complete success after a partial target modification.

[oSPANNERo]

Update on the write-path validation

A follow-up test uncovered an important edge case in the earlier write-path conclusion.

The previous validation correctly established that a readable Key B value is not treated as write authorization and that readable-only B data remains separate from recovered authentication keys. However, additional testing against a Proxmark3-emulated sector using trailer condition 010 showed that the low-level write command can report success even when the sector trailer itself is not actually modified.

In the reproduced case:

• the saved source requested sector 0 trailer ACL/GPB FF 07 80 69
• the target retained trailer ACL/GPB 7F 0F 08 69
• the Chameleon write command reported success for the trailer write
• ordinary data blocks could still be modified
• the GUI consequently reported the overall card write as successful even though the target was only partially updated

This exposed a false-success path rather than a readable-Key-B authorization issue.

Commit 25b4578 adds post-write verification for Gen2 sector trailers before a sector is treated as successfully transitioned or the recovered keys are replaced.

The verification now confirms:

• the expected new Key A can read the resulting trailer
• access-condition bytes and GPB match the requested trailer
• readable Key B data matches the requested bytes when Key B is configured as readable data
• protected Key B authenticates successfully when it is configured as an authentication key

Gen3 inherits the same verification through the Gen2 write implementation.

Regression coverage now includes:

• acknowledged-but-unapplied trailer write → overall write correctly reports failure
• applied trailer with readable Key B → verification succeeds
• applied trailer with protected Key B → verification succeeds through Key B authentication

The complete Flutter test suite currently passes 22/22, targeted trailer-write tests pass 3/3, flutter analyze reports no issues for the relevant files, and the Windows release build succeeds.