feat: add IDTECK PSK1 tag type support

[matteoscrugli]

Summary

Adds GUI support for the IDTECK PSK1 LF tag type, mirroring the firmware implementation from RfidResearchGroup/ChameleonUltra#407. Lets users save, emulate, and T55xx-clone IDTECK cards directly from the app.

Motivation

The firmware supports IDTECK emulation and T55xx writing, but the GUI has no knowledge of the TAG_TYPE_IDTECK = 310 tag type nor of the three new DATA_CMD_IDTECK_* command IDs. Slots provisioned as IDTECK via CLI currently render as "unknown" in the slot manager, and there is no way to save an IDTECK card from a CardSave dump.

Changes

helpers/definitions.dart

• Add TagType.idteck(310)
• Add ChameleonCommand.writeIdteckToT5577(3017), setIdteckEmulatorID(5010), getIdteckEmulatorID(5011)
• New IdteckCard extends LFCard (modeled on VikingCard)

bridge/chameleon.dart

• setIdteckEmulatorID, writeIdteckToT55XX, getIdteckEmulatorID
• No readIdteck — PSK demodulation is not implemented in the firmware yet

helpers/general.dart

• Display name "IDTECK", add to LF tag type list, getLFCardFromUID factory, uidSizeForLfTag = 8 bytes (preamble + payload)

helpers/write.dart, helpers/t55xx/write/base.dart

• Route IDTECK through the existing T55xx write helper (no read-back verification since readIdteck does not exist)

gui/page/slot_manager.dart, gui/menu/dialogs/slot/edit.dart, gui/menu/dialogs/slot/export.dart

• Branches to save an IDTECK CardSave into a slot, load/save the emulator ID in the slot edit dialog, and export the slot back to a CardSave

gui/page/home.dart

• Bump the firmware capability gate from setVikingEmulatorID to setIdteckEmulatorID, so users on older firmware get the "please update" prompt

Dependencies

This PR depends on firmware PR RfidResearchGroup/ChameleonUltra#407. Merging before that firmware ships will cause the capability check to fail against all currently-released firmware builds.

Testing

• flutter analyze lib/ clean (no new issues)
• flutter build macos --debug succeeds
• Tested live against a Chameleon Ultra running the firmware branch from Visualize found keys when reading card. #407, BLE and USB:
  • Slot with TAG_TYPE_IDTECK renders as "IDTECK" (was "unknown")
  • Loading a saved IDTECK card into a slot writes the emulator ID and the slot emulates correctly against a real IDTECK reader
  • Editing an IDTECK slot round-trips the frame through get/set
  • Exporting a slot to a CardSave preserves the frame
  • T5577 clone via the Write Card flow succeeds end-to-end: frame is programmed on a blank T5577, and the resulting fob is accepted by the reader
• No regressions on EM410x / HIDProx / Viking slots

Note: the Write Card flow requires the sibling one-line fix in a parallel PR (fix: switch to reader mode before T55xx write) to work correctly when the device starts in tag-emulation mode. That fix is a pre-existing bug unrelated to IDTECK but affects every T55xx write path including this one.

Not included

• readIdteck() — PSK1 demodulation on LF_OA_OUT is feasible but out of scope (firmware DSP work). Tracked as future firmware roadmap in the Visualize found keys when reading card. #407 description.
• Parsed format fields (facility code / card number) — the frame is exposed as raw 8-byte hex, following the Viking model. IDTECK sub-formats can be layered on later without breaking changes.

Pattern

The implementation follows the Viking integration 1:1 (simplest existing LF tag with raw-hex UID). Same file touches, same else-if chain placement.

[GameTec-live]

Nothing jumps out to me. Dont have a IDTECK card tho, so someone please test.

[matteoscrugli]

I've already tried it out mate. If you want more details I can give them to you.

[GameTec-live]

Not like I dont trust you, but more that "yup, works on my machine" and then it doesnt work for other people is a very common scenario.

While not as prevalent here, as basically everything is handled by firmware, its still a potential concern.

[GameTec-live]

welp... looks like, as all 3 PRs are similar and based off the same branch, merging one creates a few merge conflicts...

[matteoscrugli]

Not like I dont trust you, but more that "yup, works on my machine" and then it doesnt work for other people is a very common scenario.

While not as prevalent here, as basically everything is handled by firmware, its still a potential concern.

For what it’s worth, I’ve tried three different versions of IDTECK on my PC and on two phones. Unfortunately, it’s not a very widespread standard; I hope to see this feature on the official channel soon. Thank you for your work.

[matteoscrugli]

welp... looks like, as all 3 PRs are similar and based off the same branch, merging one creates a few merge conflicts...

If it would be helpful, I’ll create a single pull request based on the current state

[matteoscrugli]

Consolidated into #844 as you suggested, that PR bundles PAC and IDTECK into a single change set, so there are no merge conflicts between parallel branches anymore. Closing this in favour of the unified PR. Thanks for the heads-up!