fix: recover update checks after GitHub API failures

[IgorArkhipov]

Problem

1. When GitHub rate-limits its REST API, Entropy reports an update-check failure even though GitHub's public latest-release endpoint can still identify the current release.

2. On macOS, test-double HID workers also take the process-global lock that only protects real hidapi operations, creating avoidable test contention.

Fix

• Fall back to GitHub's latest-release redirect after an API failure, accepting only the canonical Entropy release URL and leaving asset download links unavailable when no asset metadata was fetched.
• Keep the macOS lock for real HID backends while skipping it for the in-process test backend.

Verification

• cargo test --locked -- --test-threads=1 — 508 passed.
• cargo test --locked — 508 passed.
• Scoped rustfmt --edition 2021 --check and git diff --check passed.
• Strict Clippy remains blocked by 73 pre-existing repository-wide warnings; this change adds none.

[kissetfall]

The fallback is useful, but this branch can no longer be merged through the app_update.rs conflict as written. Current main now owns both Entropy application updates and model-specific RMK firmware package lookup in the same release client.

Please rebase and port the change into that current owner with these constraints:

• keep the /releases/latest redirect fallback specific to the Entropy application check; it provides a tag but no asset metadata and cannot replace the RMK release-list lookup, which must find the exact model/topology archive;
• preserve the current trusted-URL and platform-asset selection logic, and add coverage showing that Entropy can report a version without an asset while RMK lookup does not silently fall back to an unrelated “latest” package;
• keep the macOS test-backend lock bypass as a separate focused commit (or separate PR) so it can be reviewed independently from network fallback behavior.

After the rebase, please run the current Entropy + RMK update tests and the full platform CI matrix.