feat(sdk-core): add root-fetch detour in getUserPrv for safe child wallets

[s84krish]

Ticket: WCN-1200

Summary

• Enable safe owner signing for child wallets whose user key has no encryptedPrv: fetch the root, decrypt with the safe passphrase, and hardened-derive the child (m/999999'/') via shared safeDerivation.ts.
• Add a signing-side accessor (resolveSafeOwnerSigningPrv) with fail-closed multisig pub verification against the registered child pub.
• Wire call sites (getUserPrv, hot-wallet signTransaction, getUserKeyAndSignTssTransaction, pending-approval TSS recreate) without detouring getPrv / getEncryptedUserKeychain (wallet sharing must not receive root material).
• Preserve sharee and SMC behavior: sharees decrypt their child encryptedPrv as-is; soft deriveKeyWithSeed remains for non-safe SMC only.

Test plan

• Unit: safe owner root fetch + hardened derive (not soft deriveKeyWithSeed)
• Unit: pub mismatch aborts locally
• Unit: sharee path — no root fetch, no soft derive (incl. explicit prv)
• Unit: SMC coldDerivationSeed still applied for non-safe wallets
• Unit: fetchRootKeychainForSafeChild rejects non-user root source
• Unit: signing guards + pending-approval safe path use getUserPrv
• Confirm wallet-share / getEncryptedUserKeychain still skips for safe owners (no root exposure)
• E2E multisig send from a safe child (tracked with WCN-1187 / WCN-1206)

[linear-code]

WCN-1200

[davidkaplanbitgo]

Even if the wallet does come from a safe - if the spender is someone who the wallet was shared with, they will not require this detour - it is only required if it is the wallet minter.

[s84krish]

Make sense, removed the large if safeId() block and just detoured to getUserPrv if it is the safe wallet minter

[pranavjain97]

nit: doesn't assert rootKeychain.id === childKeychain.parent before use, the pub-match check below catches a mismatch but an explicit assertion would make the invariant self-documenting

[s84krish]

I feel this could be a bit redundant - am okay with adding if we strongly feel it adds value though!

[pranavjain97]

nit: coldDerivationSeed now applies after decrypting encryptedPrv too, previously only for direct params.prv. no call site currently passes both together, intentional new path or unused scope creep?

[s84krish]

Thanks for calling this out, it was unintentional. No callers as you mentioned but looking to keep the existing paths the same and only add the additional path for the safe children. Closed this gap