feat: add Asset Lock derivation path subfeatures 4 and 5

[QuantumExplorer]

Summary

• Add two new DIP-9 derivation path subfeatures under feature 5' (Identity Keys):
  • Subfeature 4': Asset Lock Address Topup Funding (m/9'/coinType'/5'/4'/index')
  • Subfeature 5': Asset Lock Shielded Address Topup Funding (m/9'/coinType'/5'/5'/index')
• These provide deterministic HD derivation paths for asset lock transactions, replacing the previous OsRng approach
• Corresponding DIP-9 assignments update: docs(dip-9): add asset lock subfeatures and document key types dips#177

Changes (16 files)

key-wallet

• dip9.rs: New constants, path definitions, DerivationPathReference variants (17, 18)
• bip32.rs: New path constructors with tests
• account_type.rs: New AccountType variants (AssetLockAddressTopUp, AssetLockShieldedAddressTopUp)
• account_collection.rs: Storage fields and accessors
• managed_account_type.rs: Mutable wrappers with AddressPool
• managed_account_collection.rs: Managed account storage and creation
• managed_account/mod.rs: Address pool accessors and gap limits
• transaction_router/mod.rs: AccountTypeToCheck variants, AssetLock routing
• account_checker.rs: CoreAccountTypeMatch variants and address checking
• wallet/helper.rs: Added to create_special_purpose_accounts

key-wallet-ffi

• types.rs: FFIAccountType variants 14 and 15
• address_pool.rs, managed_account.rs, transaction_checking.rs: Match arms

key-wallet-manager

• integration_test.rs: Updated account count assertion (10 -> 12)

Test plan

• All key-wallet unit tests pass (465+)
• All key-wallet-ffi tests pass
• All key-wallet-manager integration tests pass
• cargo clippy passes
• cargo fmt passes
• FFI verification passes

Generated with Claude Code

Summary by CodeRabbit

• New Features
  • Added two new asset-lock top-up account types (standard and shielded). They are integrated across account creation, address generation, derivation paths, transaction checking, routing, and wallet lifecycle so top-up flows are fully supported.
• Tests
  • Updated integration test expectations to reflect the increased default account count.

[coderabbitai]

Warning

Rate limit exceeded

@QuantumExplorer has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 12 minutes and 15 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

📝 Walkthrough

Walkthrough

This pull request adds two new account types—AssetLockAddressTopUp and AssetLockShieldedAddressTopUp—throughout the FFI, core account types, managed account collections, derivation paths, wallet creation flows, and transaction checking, with corresponding enum, struct, and conversion updates.

Changes

Cohort / File(s)	Summary
FFI enum & conversions key-wallet-ffi/include/key_wallet_ffi.h, key-wallet-ffi/src/types.rs	Added AssetLockAddressTopUp = 14 and AssetLockShieldedAddressTopUp = 15 to FFIAccountType; updated to_account_type / from_account_type mappings.
FFI account/pool handling key-wallet-ffi/src/address_pool.rs, key-wallet-ffi/src/managed_account.rs	Extended address-pool lookups, get-by-type functions, and address-used marking to include the two new account variants.
FFI transaction matching key-wallet-ffi/src/transaction_checking.rs	Added handling for new CoreAccountTypeMatch variants; construct and push matching FFIAccountMatch entries for the new account types.
Core account types & collection key-wallet/src/account/account_type.rs, key-wallet/src/account/account_collection.rs	Added AssetLockAddressTopUp and AssetLockShieldedAddressTopUp variants; updated index/derivation mappings and added optional fields asset_lock_address_topup and asset_lock_shielded_address_topup to AccountCollection, integrated into insertion, lookup, iteration, and clear logic.
Derivation paths & constructors key-wallet/src/dip9.rs, key-wallet/src/bip32.rs	Added new DerivationPathReference variants (17,18), subfeature constants, four DIP-9 path constants for mainnet/testnet, and two DerivationPath constructors for the new top-up paths; exposed constants via crate re-exports.
Managed account types & collection key-wallet/src/managed_account/managed_account_type.rs, key-wallet/src/managed_account/managed_account_collection.rs	Added ManagedAccountType::AssetLockAddressTopUp and ...ShieldedAddressTopUp (with AddressPool); added corresponding optional fields to ManagedAccountCollection; updated index/pool/conversion and collection lifecycle methods.
Managed account plumbing key-wallet/src/managed_account/mod.rs	Extended pattern matches in address generation and retrieval flows to include the new managed account variants (treated as single-pool types).
Transaction checking core key-wallet/src/transaction_checking/account_checker.rs	Added CoreAccountTypeMatch variants for the two new account types; extended involved-address tracking, routing, matching, and account-finding to include them.
Transaction router key-wallet/src/transaction_checking/transaction_router/mod.rs	Added AccountTypeToCheck entries for the new account types; updated get_relevant_account_types and TryFrom<ManagedAccountType> (owned & borrowed) mappings.
Wallet lifecycle & helpers key-wallet/src/wallet/helper.rs	Wired creation of the two new special-purpose accounts into create_special_purpose_accounts and ..._with_passphrase; added xpub resolution support for them.
Tests key-wallet-manager/tests/integration_test.rs	Updated integration test expected account count to reflect the added accounts (expectation changed from 10 → 12).

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~50 minutes

Poem

🐇 I hopped through enums and paths anew,
Two top-up accounts in shiny view,
From FFI, pools, to router's song,
Derivation roots now stretched and strong,
A rabbit's cheer for changes true! ✨

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main change: adding two new Asset Lock derivation path subfeatures (4 and 5) to the DIP-9 specification, which is the primary objective across all modified files.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch feat/asset-lock-derivation-subfeatures

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (1)

key-wallet-ffi/src/types.rs (1)

179-182: FFI enum discriminants 14 and 15 are correctly assigned and don't conflict with existing values.

The source ordering places these variants between IdentityInvitation = 6 and ProviderVotingKeys = 7, which is slightly unusual but functionally correct since explicit discriminant values are used. Consider reordering the source to match ascending discriminant order for readability, but this is purely cosmetic.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@key-wallet-ffi/src/types.rs` around lines 179 - 182, The enum variants
AssetLockAddressTopUp (14) and AssetLockShieldedAddressTopUp (15) are correctly
assigned and non-conflicting, but their source placement between
IdentityInvitation and ProviderVotingKeys is out of discriminant order; reorder
the declarations so variants follow ascending discriminant order (e.g., move
AssetLockAddressTopUp and AssetLockShieldedAddressTopUp to appear after
ProviderVotingKeys or rearrange surrounding variants) to improve readability
while keeping their explicit discriminant values unchanged.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@key-wallet/src/account/account_type.rs`:
- Around line 56-61: Doc comments for the enum variants AssetLockAddressTopUp
and AssetLockShieldedAddressTopUp mention "Identity..." which is inconsistent
with the variant names; update the comments to say "Asset-lock..." (or "Asset
lock") so they read e.g. "Asset-lock address top-up funding (subfeature 4)" and
"Asset-lock shielded address top-up funding (subfeature 5)", keeping the
existing BIP32 paths unchanged and preserving punctuation/formatting in
account_type.rs.

---

Nitpick comments:
In `@key-wallet-ffi/src/types.rs`:
- Around line 179-182: The enum variants AssetLockAddressTopUp (14) and
AssetLockShieldedAddressTopUp (15) are correctly assigned and non-conflicting,
but their source placement between IdentityInvitation and ProviderVotingKeys is
out of discriminant order; reorder the declarations so variants follow ascending
discriminant order (e.g., move AssetLockAddressTopUp and
AssetLockShieldedAddressTopUp to appear after ProviderVotingKeys or rearrange
surrounding variants) to improve readability while keeping their explicit
discriminant values unchanged.