Fix/nut13 restore legacy derivation

[Forte11Cuba]

Description

Per NUT-13, when performing a restore for version 01 keysets, wallets MUST check secrets derived with both BIP32 legacy and HMAC-SHA256 derivation methods. Currently, restore_batch() only generates HMAC-SHA256 blinded messages for 01 keysets, causing incomplete restores when recovering proofs originally created with BIP32 derivation by older wallets.

This PR:

• Modifies restore_batch() to generate dual derivation (BIP32 legacy first, then HMAC-SHA256) for 01 keysets
• Adds from_seed_batch() for saga replay paths that need single derivation with 1:1 signature correspondence
• Adjusts counter tracking in fn restore() for the 2:1 output-to-counter ratio on 01 keysets
• Updates 4 saga replay consumers to use from_seed_batch() to prevent vector length mismatch

---

Notes to the reviewers

The key distinction is between restore/discovery (restore_batch) and replay of known operations (from_seed_batch):

• restore_batch() — sends blinded messages to the mint to discover unknown proofs. For 01 keysets, must try both derivations since we don't know which was used originally.
• from_seed_batch() — re-derives secrets for replaying our own wallet's operations (swap/issue saga recovery). These always used from_seed() which picks a single derivation per version, so 1:1 correspondence with signatures is required.

The legacy_derive() methods already existed and were functional they just were never called for Version01 during restore.

---

Suggested CHANGELOG Updates

CHANGED

ADDED

• PreMintSecrets::from_seed_batch() for re-deriving blinded messages with single derivation per keyset version

REMOVED

FIXED

• restore_batch() now generates both BIP32 legacy and HMAC-SHA256 blinded messages for 01 keysets during restore, per NUT-13 spec requirement

---

Checklist

• I followed the code style guidelines
• I ran just final-check before committing

[a1denvalu3]

NAK. I was aware of this problem and I think we can ignore it, because the main wallets are all up-to-date and equipped for the v2 keysets rollout, so there is not going to be any instance of wallets wrongly using the v1 derivation for the v2 keysets (as the spec wants to account for)

[thesimplekid]

Per discussion we said we would remove this from the spec, will leave this open as reference until that happens.