BitBox02 firmware

This commit is a small internal code cleanup in the BitBox02 hardware wallet firmware. It moves the creation of an empty on-screen placeholder component into a common hardware-abstraction layer (HAL) so that both real device code and automated test code use the same interface. There is no direct security fix here; it is a refactoring that makes the code easier to test and maintain.

This commit adds a new 'coin purchase memo' feature to BitBox02 payment requests. It lets a payment request include details about a separate coin purchase (e.g., '0.25 ETH to address 0x...') and verifies that the listed Ethereum address really belongs to the wallet by deriving it from a provided keypath. The change is mostly a feature addition, but it introduces cross-currency validation logic and a TODO noting that the user-interface confirmation for this new memo type is not yet implemented.

This commit is a routine code cleanup: it moves the progress-bar UI code behind a Rust trait (interface) so different parts of the firmware can use it through a common abstraction. It does not change security behavior, fix a bug, or add a new user-facing feature beyond the existing progress bars.

This commit is a routine code reorganization. It moves two constant definitions—how long device names and multisig account names can be—from the C code into Rust, so both the BitBox02 and future BitBox03 products can share the same values. The actual length limits (63 characters plus a null terminator for device names, 30 plus null for multisig names) are unchanged, and the commit adds compile-time checks to prove they stay the same. There is no security bug being fixed here.

This commit only cleans up test code by removing unnecessary calls to a mock memory setup function. It does not change the actual firmware that runs on the BitBox02 device, so it has no security impact on users.

This commit is a straightforward internal code refactor. It introduces a new 'KeystoreHal' adapter so that the keystore code can borrow only the hardware subsystems it needs (memory, random number generator, secure chip) instead of borrowing the entire HAL, which also contains the user interface. The stated reason is to allow a UI animation to run in parallel while the device unlocks. There is no change to security logic, cryptography, or user-facing behavior.

This is a small internal code cleanup in the BitBox02 firmware's Rust code. It changes a helper function so it borrows only the memory/storage part of the hardware abstraction layer, rather than the whole hardware abstraction layer. The commit message says this is preparation for a future change where the user interface part of the hardware layer will be used at the same time during wallet unlocking. There is no direct security fix here and no vulnerability is described.

This commit simply moves a function from one Rust source file to another. The code itself is unchanged; only its location in the project changed. There is no indication of a security fix or vulnerability.

This commit simply moves a function called rust_salt_hash_data from one Rust source file to another. The function itself is unchanged; only its location and the associated test code are reorganized. There is no indication this fixes or introduces a security problem.

This commit is a routine code reorganization. It moves two C-callable Rust functions related to Bluetooth Low Energy (BLE) communication mode from one Rust source file to another, and adjusts which Rust crate features enable the relevant code. There is no visible change to what the code does, only where it lives in the project. No security issue is evident from the diff.

This commit is a straightforward internal code reorganization. It moves the C-compatible entry point for the device's main loop from one Rust module to another, so that the core Rust logic no longer directly depends on the hardware abstraction layer. There is no change to user-facing behavior, no bug fix, and no security-related content.