fix: surface locked Trezor as DeviceBusy via trezor-connect-rs 0.3.4

Bump trezor-connect-rs to 0.3.4 and map the new typed ThpError::DeviceLocked
to TrezorError::DeviceBusy, so a locked Trezor during the THP handshake is
surfaced as the typed back-off signal instead of a generic ConnectionError.
Mobile clients can prompt the user to unlock rather than reconnecting in a loop.

0.3.4 also classifies DeviceLocked as non-retryable upstream: it no longer
churns the transport (close/reopen loop) on a locked device and instead makes a
single try_to_unlock handshake attempt so the device prompts for unlock.

Regenerates the iOS/Android/Python bindings via ./build.sh all (compiled
artifacts only; the UniFFI interface is unchanged since DeviceBusy already
existed).

Author: coreyphillips

CHANGELOG.md

@@ -1,5 +1,9 @@
 # Changelog
 
+## Unreleased
+
+- Surface a locked Trezor during the THP handshake as the typed `TrezorError::DeviceBusy` instead of a generic connection error, so mobile clients back off and prompt the user to unlock rather than reconnecting in a loop. Backed by `trezor-connect-rs` 0.3.4, which classifies `DeviceLocked` as a distinct, non-retryable state: it no longer churns the transport (close/reopen loop) on a locked device and instead makes a single `try_to_unlock` handshake attempt so the device prompts for unlock.
+
 ## 0.3.3 - 2026-06-22
 
 - Surface wrong/cancelled/expected Trezor PIN failures as typed `TrezorError` variants (`InvalidPin`, `PinCancelled`, `PinRequired`) instead of generic device errors, so mobile clients can clear the PIN spinner, prompt a deliberate retry, and avoid reconnecting while the device is mid-flow. Backed by `trezor-connect-rs` 0.3.3, which maps protocol `Failure` codes to typed errors; unknown failure codes remain generic `TrezorError::DeviceError`.