Fix checksum validation and property ID corruption in card modification

[KikoTs]

Problem

When modifying Saflok cards, two critical bugs caused:

• Property ID to change unexpectedly (e.g., 3573 → 3317)
• Checksum to become invalid, showing "Checksum Valid: No" in Flipper Zero Momentum firmware

Root Causes

1. Creation Year Decoding Bug

The order of operations in decode_card() was incorrect compared to the C implementation:

Before (incorrect):

card['creation_year'] = (((dcard_data[11] & 0xF0) >> 4) + 1980) | card['creation_year_bits']

After (fixed):

card['creation_year'] = ((card['creation_year_bits'] | ((dcard_data[11] & 0xF0) >> 4)) + 1980)

This bug caused creation_year_bits to be calculated incorrectly during re-encoding, corrupting byte 14 which contains both the creation year bits and the property ID high bits.

2. Alice Initialization Bug in Encryption

The encrypt_card() function had a critical flaw in calculating the alice bit used for the bit-shuffling algorithm. The alice value is derived from dc[10] & 1 after stage 1 decryption, creating a circular dependency where:

• Alice affects encryption → encryption affects dc[10] → dc[10] determines alice

Solution: Test both possible alice values (0 and 1) and select the one that produces a self-consistent result. When both work, prefer alice=1 based on empirical testing.

Impact

• ✅ Property ID now remains unchanged during card modification
• ✅ Checksum validation passes ("Checksum Valid: Yes")
• ✅ Full encrypt/decrypt cycle preserves all card data correctly
• ✅ Compatible with Flipper Zero Momentum firmware expectations

Testing

Verified with real Saflok card data that modifying only the key level preserves the property ID (3573) and generates valid checksums.