[DRAFT] Add Winternitz/XMSS rotation and ML-DSA-44

[L0STE]

Draft: Publish solana-winternitz and solana-ml-dsa first, including the required solana-shake revision, then replace the local/git dependencies. The new program IDs are local and undeployed.

This adds Winternitz, XMSS and ML-DSA-44 authorization to Vector. Each has its own program and verifier adapter, using the existing transaction digest, Advance and Passthrough flow.

• Winternitz: 849-byte signatures, one signing attempt per key, optional key rotation.
• XMSS: 1,037-byte signatures, 256 signing attempts per tree, optional key rotation.
• ML-DSA-44: 2,420-byte signatures, a fixed public key and stateless signing, like Falcon.

Winternitz and XMSS use the DKKW25 constructions in solana-winternitz, with target-sum encoding and Keccak-256. This XMSS variant is not compatible with RFC 8391.

Their 106-byte accounts separate a permanent identity from the current verification key:

nonce[32] || bump[1] || identity[32] || current_public_key[41]

Initialization sets identity = sha256(initial_public_key). It remains the PDA seed and digest identity after rotation, so assets and downstream authorities keep the same address. To rotate:

Advance(current-key signature)
Passthrough([Rotate(next_public_key), ...actions])

The signed digest commits to the replacement key and every action. Rotate changes only the stored key and uses the same PDA-signer authorization as Withdraw and Close. Rotation is optional and stays within the account's scheme. Callers manage key freshness, leaf allocation and persistent signing state; the program does not track spent keys or require a replacement to differ. Retaining control requires Winternitz callers to rotate in their one authorization and XMSS callers to rotate before exhaustion.

Rotation and actions are atomic. A failed transaction restores the nonce and current key. Saved authorizations can be retried unchanged when the failure is resolved. A permanently failing action cannot be repaired by signing a different transaction with a spent Winternitz key; this PR does not introduce a separate recovery authorization.

ML-DSA-44 uses solana-ml-dsa with SHAKE128/256 and an empty FIPS 204 context. The message is Vector's 32-byte transaction digest. Its 21,892-byte account stores:

nonce[32] || bump[1] || public_key[1312] || pad[3] || prepared_key[20544]

Following Falcon's approach, the program prepares the key once on chain. Registration is Initialize followed by two permissionless Expand instructions, each growing the account by at most 10,240 bytes. Account length records progress; Advance rejects incomplete accounts. Registration takes about 1.1M CU and verification about 264K CU in local tests. Registration and authorization require V1 transactions; callers provide the transaction limits and submission.

The Rust and TypeScript SDKs provide scheme descriptors and instruction builders. Rust ML-DSA signing uses an external signer; TypeScript uses Noble's ml_dsa44. Both expose offline verification. Passthrough builders also preserve external co-signers while clearing only the PDA's outer signer flag.

Validation: ML-DSA SBF build, 42 Rust tests, 14 offline TypeScript tests, TypeScript compilation and Clippy. Coverage includes full-transaction registration, incomplete-account rejection, external signatures, context mismatch, replay, Rust/TypeScript digest parity, SPL authority handoff, and rotation rollback followed by an unchanged retry. Checked against solana-ml-dsa at 75a5b38 and solana-winternitz at d6c381a. Live-cluster validation remains outstanding.