feat: add experimental generic FROST HD derivation

[JW-Rami]

This PR adds a new experimental crate frost-hd, which defines non-hardened hierarchical key derivation for FROST key packages in a ciphersuite-generic, blockchain-agnostic way.

---

The construction derives child key material by applying the same additive tweak to each participant signing share, each participant verifying share, and the joint verifying key. This lets a FROST group derive descendant key packages for arbitrary non-hardened paths without changing the underlying signing protocol.

To support this cleanly, this PR adds:

• a new frost-hd crate with typed derivation paths, explicit context binding, derivation-key handling, error types, vectors, and documentation;
• private and public derivation wrappers around KeyPackage and PublicKeyPackage;
• Ed25519, Ristretto255, and secp256k1 test coverage;
• reference Python models and a draft RFC for the construction and its security model.

The scope is intentionally limited. This PR does not claim BIP32 compatibility, does not claim SLIP-0010 compatibility, and does not implement hardened derivation. The child derivation model is explicitly related-key: disclosure of a child share reveals the corresponding parent share for that participant.

This is experimental and unaudited. It is not being proposed as production-ready wallet infrastructure. The goal is to upstream the generic construction and the surrounding review surface, while keeping chain-specific adapters and hardened derivation out of scope.

Background and prior upstream discussion

This PR is not introducing this topic out of nowhere. There is already upstream discussion and visible demand for FROST hierarchical derivation work:

• Discussion #636, "BIP32 Derivation of FROST Keys" opened the dedicated upstream thread for non-hardened derivation of FROST keys. The original motivation there was deriving new keys without running a new DKG each time, and maintainer feedback explicitly said on April 16, 2024 that this is something the project is interested in. I followed up on April 30, 2026 asking whether there was any news. As of July 31, 2026, I do not see a public reply to that follow-up in the discussion thread, so I decided to propose a concrete implementation for review.
• In PR #584, the BIP32 topic came up directly during the Taproot work. The thread records both the motivation for unhardened derivation and the conclusion that it should be handled separately rather than widening the Taproot PR's scope. See in particular MatthewLM's comment, conduition's response, and the follow-up that moved the topic into discussion #636.
• In PR #730, the follow-on need remained explicit. The PR body lists BIP32 key derivation as a next feature, and this comment points to a separate taproot-bip32 branch as useful so that FROST keys can be used in hierarchical and descriptor wallets.

This PR is intended as that follow-on work, but in a ciphersuite-generic and blockchain-agnostic form. Its scope remains limited to non-hardened derivation, and it does not claim BIP32 or SLIP-0010 compatibility.

Some additional features we can consider adding:

• hardened or threshold-interactive derivation
• chain-specific wallet adapters layered on top of the generic crate
• reviewed ciphersuite-specific derivation hooks beyond the current experimental profile surface
• stabilization of any public API that should live in frost-core rather than an adjacent experimental crate

[JW-Rami]

@conradoplg hey - I would love it if you could take a look when you have a chance. This topic came up in the earlier discussion and I finally went ahead and opened a concrete implementation for review.

[JW-Rami]

let me know if you have any questions!