chore: bump leanVM to e2592df on devnet5

[MegaRedHand]

Motivation

Track upstream leanVM at e2592df (the repo's devnet5 branch), previously 8fcbd779 (#408).

Description

The aggregation crate renamed its public API since 8fcbd779. ethlambda-crypto adapts to the new names; shapes, fields, and call signatures are unchanged, so the port is mechanical:

Old (8fcbd779)	New (e2592df)
TypeOneMultiSignature	SingleMessageAggregateSignature
TypeTwoMultiSignature	MultiMessageAggregateSignature
aggregate_type_1	aggregate_single_message_signatures
merge_many_type_1	merge_single_message_aggregates
split_type_2	split_multi_message_aggregate
verify_type_1 / verify_type_2	verify_single_message_aggregate / verify_multi_message_aggregate

Plonky3 pin: p3-* crates are pinned back to 3f67d136 (the rev devnet5 already used). Newer revs pulled in transitively by leanVM use the unstable maybe_uninit_slice feature, which doesn't build on Rust 1.92.0.

Validation

• ✅ cargo build --workspace
• ✅ cargo clippy -p ethlambda-crypto clean
• ✅ cargo fmt --check clean

Notes

• The heavy round-trip tests (aggregate/verify/merge/split) remain #[ignore] (12+ GiB/proof), so semantic correctness here is verified by compile + prover setup, not a live proof.
• test_setup_is_idempotent stack-overflows in debug builds: the new bytecode compiler needs >2 MiB of stack. Release is unaffected and make test uses --release, so CI passes; flagging for awareness.

[greptile-apps]

Greptile Summary

This PR tracks the upstream leanVM repo rename (previously leanMultisig) and adapts ethlambda-crypto to the new public API, all of which are mechanical identifier renames with no shape or signature changes. Plonky3 is pinned back to 82cfad73 to avoid a nightly-only maybe_uninit_slice dependency pulled in by the newer leanVM transitive rev.

• API rename: TypeOneMultiSignature / TypeTwoMultiSignature and all associated free functions (aggregate_type_1, merge_many_type_1, split_type_2, verify_type_1/2) are mapped to their new equivalents; call sites, field accesses, and error handling are otherwise unchanged.
• Dependency updates: rayon is replaced by leanVM's internal parallel crate, num-bigint is downgraded within leanVM internals, and windows-sys is bumped across several registry crates.
• Known caveat: test_setup_is_idempotent stack-overflows in debug builds (new bytecode compiler needs >2 MiB stack); --release is unaffected and is what CI uses.

Confidence Score: 4/5

Safe to merge — all changes are mechanical API renames driven by an upstream repo restructure, with no logic, field, or call-signature changes.

The port is straightforward: every old identifier maps 1-to-1 to a new name, field accesses and error handling are untouched, and the PR reports a clean build plus passing setup test. The one doc-comment naming slip and the acknowledged debug-build stack overflow are the only rough edges.

No files require special attention beyond the minor doc-comment fix in crates/common/crypto/src/lib.rs.

Important Files Changed

Filename	Overview
crates/common/crypto/src/lib.rs	Mechanical rename of all leanVM API identifiers (TypeOne/TypeTwo → SingleMessage/MultiMessage, aggregate_type_1 → aggregate_single_message_signatures, etc.); one doc-comment references a non-existent function name.
crates/common/crypto/Cargo.toml	Git source URLs updated from leanMultisig to leanVM at rev 3f2116d for lean-multisig and leansig_wrapper dependencies.
Cargo.lock	Lock file updated: leanVM rev bump, rayon replaced by the internal parallel crate, Plonky3 pinned back to 82cfad73 to avoid nightly-only maybe_uninit_slice, windows-sys bumped across various registry crates.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[ethlambda-crypto] -->|imports| B[lean-multisig\nleanVM @ 3f2116d]
    A -->|imports| C[leansig_wrapper\nleanVM @ 3f2116d]

    B --> D[aggregate_single_message_signatures\nwas: aggregate_type_1]
    B --> E[merge_single_message_aggregates\nwas: merge_many_type_1]
    B --> F[split_multi_message_aggregate\nwas: split_type_2]
    B --> G[verify_single_message_aggregate\nwas: verify_type_1]
    B --> H[verify_multi_message_aggregate\nwas: verify_type_2]
    B --> I[SingleMessageAggregateSignature\nwas: TypeOneMultiSignature]
    B --> J[MultiMessageAggregateSignature\nwas: TypeTwoMultiSignature]

    C --> K[XmssPublicKey / XmssSignature\nunchanged]

    B -.->|transitively uses| L[Plonky3 @ 82cfad73\npinned back from 750f990e\nto avoid nightly feature]
    B -.->|replaced rayon with| M[parallel crate\ninternal to leanVM]

Loading

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
crates/common/crypto/src/lib.rs:386
The doc comment names `split_multi_message_aggregate_by_message`, but the actual upstream function called two lines below is `split_multi_message_aggregate` (no `_by_message` suffix). A reader cross-referencing the comment against the leanVM source will come up empty.

```suggestion
/// Mirrors leanSpec PR #717 `split_multi_message_aggregate`: the caller
```

_{Reviews (1): Last reviewed commit: "chore: bump leanVM to 3f2116d on devnet5" | Re-trigger Greptile}

[greptile-apps]

The doc comment names split_multi_message_aggregate_by_message, but the actual upstream function called two lines below is split_multi_message_aggregate (no _by_message suffix). A reader cross-referencing the comment against the leanVM source will come up empty.

Suggested change

	/// Mirrors leanSpec PR #717 `split_multi_message_aggregate_by_message`: the caller
	/// Mirrors leanSpec PR #717 `split_multi_message_aggregate`: the caller

Prompt To Fix With AI

This is a comment left during a code review.
Path: crates/common/crypto/src/lib.rs
Line: 386

Comment:
The doc comment names `split_multi_message_aggregate_by_message`, but the actual upstream function called two lines below is `split_multi_message_aggregate` (no `_by_message` suffix). A reader cross-referencing the comment against the leanVM source will come up empty.

```suggestion
/// Mirrors leanSpec PR #717 `split_multi_message_aggregate`: the caller
```

How can I resolve this? If you propose a fix, please make it concise.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!