Fix undefined 32-bit shift that traps on arm64 (daemon crashes on card read)

[hyperbotsx]

What breaks

When Moolticute is compiled natively for Apple Silicon (arm64), moolticuted crashes every time a card CPZ is read — i.e. on every device connect/unlock, which makes the app unusable. Crash reports from a Mooltipass Mini BLE on macOS 26.5.2 (M-series Mac) are deterministic:

exception: EXC_BREAKPOINT (SIGTRAP)
0  moolticuted  FilesCache::setCardCPZ(QByteArray) + 1376
1  moolticuted  MPDevice::getCurrentCardCPZ()::$_36::operator()(QByteArray const&, bool&) + 644
2  moolticuted  MPCommandJob::start(QByteArray const&)::$_0::operator()(...) + 64
3  moolticuted  MPDevice::newDataRead(QByteArray const&) + 4160
4  moolticuted  MPDevice::platformDataRead(QByteArray const&) + 52
5  moolticuted  _read_report_callback(...) + 72
6  IOKit        __IOHIDDeviceInputReportApplier + 72

Why

FilesCache::setCardCPZ() and MPDevice::getUInt64EncryptionKeyOld() derive the SimpleCrypt key from the 8-byte card CPZ like this:

for (int i = 0; i < std::min(8, cardCPZ.size()); i++)
    key += (static_cast<unsigned int>(cardCPZ[i]) & 0xFF) << (i * 8);   // i*8 reaches 56

The shifted operand is 32-bit, so for i >= 4 this shifts by 32..56 — undefined behaviour. x86 silently wraps the shift count modulo 32, which is what every historical Intel build actually computed. For arm64, clang proves those iterations are undefined and emits a trap instead: disassembling the built binary shows brk #1 (0xd4200020) at exactly the crash offset inside FilesCache::setCardCPZ.

The unit tests don't catch it — none exercise the CPZ path, so the suite passes 63/63 on an arm64 CI runner while the app crashes against real hardware.

Note that MPDevice::getUInt64EncryptionKey() (the SIMPLE_CRYPT_V2 path) already does this correctly in 64-bit; only the legacy path and the FilesCache copy were left with the undefined shift.

The fix

Mask the shift count ((i * 8) & 31) so the historical x86 wrapping becomes explicit and well-defined. Derived keys stay byte-identical to what existing Intel installs produce, so cached data and SimpleCrypt-encrypted exports continue to decrypt — no migration and no data loss. The V2 path is untouched.

The second commit is related and was found alongside it: _read_report_callback() in src/MPDevice_mac.cpp ignored the IOReturn result argument. IOKit invokes that callback with an error result (and a meaningless buffer/length) when a device drops mid-read — for example while a BLE device re-enumerates its interfaces — and those bytes were parsed as if they were a real device message. Errored reports are now discarded.

Verification

Built on a macos-14 (arm64) runner and tested on hardware (Mooltipass Mini BLE, macOS 26.5.2):

• Before: the daemon crash-loops on 100% of unlock attempts; the GUI briefly shows unlocked, then resets to "daemon is not running".
• After: unlock works and holds, and device detection, credential read/write (persisting across replug), browser-extension login through the daemon WebSocket, mc-cli, notes read/write, device settings change/revert, and unplug/replug recovery all pass. A binary check confirms no brk remains in FilesCache::setCardCPZ.

Related to #1254 and #1255 (native Apple Silicon builds), but this fix is independent of any build-pipeline change — it is a latent correctness bug in the codebase that only manifests once the code is compiled for arm64.

[limpkin]

(unless I'm mistaken) and that's why AI isn't there yet: for the same input, this change will lead to different m_key outputs as nothing will be populated after the 32th bit.
https://github.com/mooltipass/minible/wiki/Mooltipass-Database-Model#-cpz-lookup-table