MIFARE Ultralight AES (MF0AES20) support #1057

Feature

Add native MIFARE Ultralight AES (MF0AES20) support to the NFC app.

Today the firmware detects UL-AES but treats it as identity-only — it cannot authenticate,
read the protected memory, write, or emulate it. UL-AES is the AES-128 successor to Ultralight-C
and is increasingly used for access/transit, so it deserves the same first-class treatment
Ultralight-C already has.

Proposed scope (Ultralight-C parity, plus UL-AES specifics)

• AES-128 3-pass mutual authentication (DataProtKey).
• Read of the protected memory once authenticated.
• Dictionary attack (user + system dicts) and manual Unlock with a typed key, mirroring
  the Ultralight-C experience.
• Recovered key shown and saved with the dump (in real tag byte order); site-key management under
  Extra Actions.
• Write a saved dump back to a card (Keep Key / Copy Key; user data pages + optionally the
  DataProtKey; config/lock pages left untouched).
• Emulation so a reader can run the 3-pass auth and read the AUTH0/PROT-gated memory (key
  pages never leak).
• The three one-way counters, configuration-page decoding in the info view, and Random-ID reveal.
• Secure messaging (CMAC) end-to-end: read, counter reads, write-back, and emulation, with
  the command counter and message MACs per datasheet §8.8.3.

Out of scope (for now)

• The 48-byte ECC originality signature (READ_SIG) — MfUltralightSignature holds 32 bytes and
  UL-AES needs 48; deferred.

Notes

• Reference: NXP MF0AES20 datasheet + Proxmark3 (cmdhfmfu.c / mifareutil.c). Note PM3 does
  not implement the secure-messaging protocol — only detects the SEC_MSG_ACT bit — so the
  CMAC framing here is datasheet-derived.
• Implementation is being tracked in a draft PR. It is not yet hardware-validated on a real
  MF0AES20 — a dedicated secure-messaging QA plan is included in the branch.