fix: protect BitBox pairing against stale hash on re-pair

[TaprootFreak]

Summary

• Snapshot getChannelHash() before starting init() and require the polled hash to differ from it
• Drop the _pendingInit ?? Future.value(true) fallback in confirmPairing and use the bang assertion the state guard already guarantees

Why

Stale hash on re-pair

BitboxService is registered as a DI singleton (lib/setup/di.dart:121), and the BitboxManager instance inside it persists across pairings. The connect modal is reachable from at least two entry points (welcome_page.dart, kyc_registration_page.dart), and any second pairing attempt within the same app session goes through that same SDK instance.

Before this PR, the polling loop accepted any non-empty hash. If bitboxManager.getChannelHash() still holds the previous session's hash when polling starts, the app shows the old hash while the BitBox displays the new one — codes don't match, user is stuck.

The 500 ms first-iteration delay introduced in #305 (...so the SDK can finish setting up its Go-side device pointer...) confirms there is a real timing gap during which the SDK is not yet up-to-date for the new session, which is precisely the window where stale hashes surface.

The fix records the hash once before init() runs and ignores any polled hash that matches the snapshot.

?? fallback in confirmPairing

_pendingInit ?? Future.value(true) silently substitutes "init succeeded" if the future is missing. The is! BitboxCheckHash state guard at the top of confirmPairing already guarantees that connectToBitbox set _pendingInit. The fallback only triggers in an impossible state, and if that state ever became reachable, returning true would let channelHashVerify() run on an unverified channel — exactly the crash #301 set out to prevent.

Replacing it with the bang assertion makes the precondition explicit and matches the project's bang usage in similar state-guarded code paths.

Changes

• lib/screens/hardware_connect_bitbox/bloc/connect_bitbox_cubit.dart: add priorHash snapshot + hash != priorHash check in polling; replace ?? fallback with bang on _pendingInit

Test plan

• Happy path on iOS BitBox02 Plus: open Welcome → pair → wallet creates (regression check, no behavioural change expected on first pair)
• Re-pair in same session: pair successfully → trigger a second pairing without restarting the app (e.g. via KYC retry flow, or by opening the connect modal again). Verify the code shown in app matches the code on the BitBox — not the previous session's code
• Cancel during BitboxConnecting (swipe modal down before code appears): no StateError, no orphaned timer (regression check for fix: prevent orphaned timer leak on BitBox modal dismiss #303)