Support LeanSig as a hash-based post-quantum application signature scheme

## Motivation

Miden currently supports Falcon512-Poseidon2 verification as a post-quantum signature option. Falcon is lattice-based and stateless. We should explore LeanSig as a complementary hash-based post-quantum signature scheme at the application/account authentication layer.

The main motivations are:

- The Ethereum Foundation's PQ team is actively developing and testing LeanSig/leanXMSS for lean Ethereum.
- Hash-based signatures rely primarily on the security of the underlying hash function, providing a comparatively conservative post-quantum assumption.
- Supporting both hash-based and lattice-based signatures gives applications cryptographic diversity instead of relying on a single post-quantum family.
- LeanSig's synchronized epoch model maps naturally onto blockchain applications that already maintain ordered account or protocol nonces.

Relevant EF work:

- https://pq.ethereum.org/
- https://github.com/leanEthereum/leanSig
- https://eprint.iacr.org/2025/055.pdf

The recently disclosed improved attack against HAWK is a slight additional motivator for this diversity. The attack exploits a HAWK-specific lattice automorphism and reduces the demonstrated HAWK-256 key-recovery cost from approximately 2^64 to 2^38 operations. It remains an exponential attack and does not affect Falcon, other NIST post-quantum candidates, or lattice cryptography generally.

This should therefore not be interpreted as evidence that Falcon is vulnerable. It is simply a reminder that maintaining diversity across post-quantum assumptions is useful.

Reference: https://www.anthropic.com/research/discovering-cryptographic-weaknesses

## Proposed Miden instantiation

Add an experimental Miden-native LeanSig implementation consisting of:

- A verifier in the Miden core library, implemented in MASM.
- Matching Rust key generation, signing, verification, serialization, and advice encoding under `miden-crypto::dsa`.
- A persisted monotonic epoch/nonce cursor that rejects reused or skipped one-time keys.
- End-to-end tests in which the Rust signer generates a signature consumed by the MASM verifier.

The construction should retain LeanSig's generalized-XMSS flow and lifetime-2^32 target-sum parameters:

- Dimension: 46
- Winternitz base: 8
- Target sum: 200
- Merkle depth: 32
- SHAKE128 secret-key PRF

Unlike the current EF LeanSig instantiation, the Miden version would use the Goldilocks field and Miden-native Poseidon2 rather than KoalaBear Poseidon1. It will therefore not be wire-compatible with EF LeanSig. The exact Miden hash layouts and domain separation must be specified and reviewed as a distinct cryptographic instantiation.

LeanSig itself is not tied to Poseidon1. The generalized construction can be instantiated with other hash functions, and BLAKE3 is also being considered. Poseidon2 is the initial Miden target because it is native to Miden VM; the implementation should keep the hash-specific boundary sufficiently isolated to support a future BLAKE3 instantiation.

## Preliminary comparison

These numbers describe the current Miden WIP implementation, not general properties of the two schemes.

| Property | LeanSig Poseidon2 WIP | Miden Falcon512-Poseidon2 |
|---|---:|---:|
| Security family | Hash/XMSS | NTRU lattice |
| Signer state | One-use epoch state | Stateless |
| MASM verification | 29,383 cycles | ~59,859 cycles |
| Verifier advice | 324 felts | ~2,057 felts |
| Serialized signature | 2,528 bytes | 1,524 bytes including expanded key |
| Public key | 64 bytes | 897 bytes |
| Primary operational risk | Nonce rollback/reuse | Complex Gaussian/floating-point signing |

LeanSig should be considered a complement to Falcon, not a replacement. Its verifier is cheaper and requires substantially less advice, but the stateful signer has stronger operational requirements and a larger serialized signature.

## Security and state-management requirements

Reusing an epoch with two different messages can compromise an XMSS-style key. An in-memory cursor and serialized counter are not sufficient protection against crashes, restored backups, concurrent signer instances, or storage rollback.

Before use by Miden Client, signing must use rollback-resistant persistent state with an atomic flow such as:

1. Reserve and burn the next epoch.
2. Durably persist the updated cursor.
3. Generate or release the signature.
4. Never restore the key independently of its nonce state.