[cryptography] reject ed25519 signatures with non-canonical S at decode time

[0xAysh]

Problem

ed25519::Signature::read_cfg accepted any 64-byte sequence without validation. A signature with S >= l (the ed25519 group order) would decode successfully but fail verification later. This is inconsistent with the rest of the codebase:

• ed25519::PublicKey::read_cfg calls VerificationKey::try_from — validates the compressed Edwards point at decode time
• secp256r1::Signature::read_cfg calls p256::ecdsa::Signature::from_slice — validates R and S at decode time
• ed25519::Signature::read_cfg — previously did nothing beyond confirming 64 bytes were present

Non-canonical S values introduce signature malleability: two different byte sequences (S and S mod l) decode to logically equivalent signatures since verification reduces S mod l. In adversarial environments this matters — a valid signature can be transformed into a "different" one that also passes verification.

Fix

Add a canonicality check for S (bytes 32..63 of the signature) in read_cfg. S must be in [0, l-1] where:

l = 2^252 + 27742317777372353535851937790883648493

The check compares S against l byte-by-byte from the most significant byte down (required because S is stored little-endian — index 0 is the LSB, so Rust's default lexicographic array comparison would be incorrect here).

The ed25519_consensus library does not expose standalone signature validation without a message, so the R component (bytes 0..31) cannot be validated at decode time without adding a dependency on curve25519-dalek. Only S canonicality is checkable, which is the primary malleability concern.

Tests

• test_high_s_rejected_at_decode: S with high bit set (S >= 2^255 >> l)
• test_s_equal_to_l_rejected_at_decode: S == l exactly (boundary — valid range is [0, l-1])
• test_s_above_l_rejected_at_decode: S == l+1

Closes #1070