fix(sdk): late-init BLE signer must use the identity AK, not a random keypair (fixes bilateral σ verification)

[cryptskii]

The bug

The bilateral σ_A/σ_B signatures must be signed by — and verified against — the device's genesis-v2 identity AK, the same key the QR/BLE pairing pins as the contact AK (derive_device_ak_keypair(wallet_seed, genesis, slot=0, policy); spec TRACEABILITY.md, ADR 0002 row 9). There is no separate bilateral/session signing key and no cert layer on the σ path.

But ensure_bluetooth_manager_and_sync_contact (dsm_sdk/src/bluetooth/mod.rs) minted a random SignatureKeyPair::new() for the BilateralTransactionManager it late-registers. When a QR contact is added before init_dsm_sdk registers the canonical AK-keyed manager, this fallback wins the global-signer OnceLock race (first-writer-wins), and the canonical manager is discarded ("already registered"). σ is then signed with a random key the peer never pinned → every bilateral transfer fails σ verification: invalid counterparty signature (σ_B) — response lost.

Why it surfaced now

The rows 6/7 fix (#627) made the receiver verify σ against the pinned AK instead of the wire-overwritten key. The old behavior — overwriting contact.public_key with the wire signing key on every prepare — masked this bug by promoting the random wire key into the trust-root slot so σ verified tautologically. With rows 6/7 correct, the random-signer mismatch became fatal.

This was found by a full source provenance trace of all three key roles (σ-signer, wire key, QR-pinned AK), which showed they are all meant to be the byte-identical identity AK.

The fix

Derive the signing keypair from the cached wallet seed exactly as the canonical path (init.rs), and refuse to register (Ok(false)) when the seed is locked — rather than minting a non-AK key that can hijack the signer slot. Both managers then hold the byte-identical identity AK, so whichever wins the OnceLock race signs σ with the pinned AK.

let keypair = match RecoverySDK::get_cached_wallet_seed() {
    Some(seed) => derive_device_signing_keypair(&seed, &gen_fixed)?,   // the identity AK
    None => return Ok(false),                                          // no random-key hijack
};

Hardware evidence (8XK ↔ 9FF, release .so)

Direct before/after on the rig:

• Before: Invalid operation: invalid counterparty signature (σ_B) — response lost (transfer dies at step 2).
• After: Session moved to Accepted phase → send_bilateral_confirm ... ConfirmPending → receiver §11.1 per-step EK A-side verification PASS (reaches step 3, post-crypto). No "signing AK differs" warning — the wire signing key now equals the pinned AK.

Scope / evidence boundary

• This PR (independent of BLE P0 (release-blocking): authenticate the BLE-delivered ML-KEM key against the pinned AK before caching (ADR 0002 rows 8/9) #628): remove the random fallback signer; make late-init derive/use the canonical genesis-v2 identity AK. Fixes bilateral σ verification on main.
• BLE P0 (release-blocking): authenticate the BLE-delivered ML-KEM key against the pinned AK before caching (ADR 0002 rows 8/9) #628 (separate): detached ML-KEM binding in the BLE prepare request/response, verify-before-cache, android cfg plumbing (rows 8/9).
• Not covered here: full offline-bearer settlement still needs the Pico anchor appliance — the run gets through the entire trust/crypto path and then fails closed at MissingRelease because no anchor is connected; balances stay unchanged.