BitBox02 firmware

This is a routine code cleanup commit that reorganizes how two internal Rust software components connect to each other. It removes a circular dependency where a higher-level crate called 'bitbox02-rust' depended on a lower-level crate called 'bitbox02', and vice versa. The change moves a small piece of noise-cryptography-related code into the lower-level crate and adjusts build configuration files accordingly. There is no indication this fixes a security vulnerability or changes user-visible behavior.

This is a minor Python import cleanup in a developer/test script. It changes how one internal class is imported so that the script works reliably when installed in 'editable' mode. There is no security issue here.

This commit is a routine internal refactoring: it moves the lookup of which secure chip type (ATECC or Optiga) is present from an older C memory module to a newer Rust memory module. The actual chip-detection logic and behavior do not change; only which internal API is called. There is no indication this fixes or introduces a security vulnerability.

This commit is a software architecture cleanup: it moves some type definitions and helper functions so that secure-chip code (ATECC/Optiga) no longer depends directly on the BitBox02-specific memory module. The goal stated by the developer is to make those modules reusable in a future BitBox03. There is no direct evidence in the commit that it fixes a security vulnerability, changes cryptographic behavior, or introduces a bug.

This commit hardens the project's automated CI workflow in two ways: it pins a third-party Mattermost notification action to a specific, unchangeable version (instead of a moving 'master' branch), and it restricts the job's GitHub token permissions to read-only access to repository contents. These are defensive security improvements that reduce supply-chain and privilege risks, but the commit itself does not fix an active vulnerability.

This commit fixes a bug in the BitBox02 hardware wallet's Ethereum transaction signing. When signing an Ethereum transaction whose 'data' field is exactly 1 byte long and is streamed from the host computer in chunks, the device could call for the first byte before it had actually been fetched, leading to a crash or failed signing. The fix makes the first-byte lookup asynchronous so it can request the byte from the host on demand, and avoids asking for an extra chunk when the whole payload is just that one byte. New unit tests and regenerated test vectors confirm the 1-byte case now works.

This commit only changes how wallet addresses are shown on the BitBox02 screen. It inserts spaces every four characters (for example, a Bitcoin address becomes "bc1q k5f9 em9q ..." instead of one long string). There is no code that changes security logic, cryptography, or how transactions are approved. It is a user-experience improvement to make long addresses easier to read and compare.

This commit swaps out an old C ringbuffer for a new Rust-based byte queue used to hold data sent to the Bluetooth chip. The change touches many files but is mostly a rewrite/refactor. It removes several explicit 'will it fit?' size checks before adding data to the queue, and it changes how callers pass the queue around. The Rust ByteQueue implementation itself is not shown in the diff, so we cannot verify whether it safely handles overflow, memory allocation failures, or concurrent access. The change is therefore a security-relevant refactor with some risk, but no proven vulnerability is visible in the supplied commit.