version bumps, MAX_RECV_SEEN patch, FIPS interop, doc updates

soliton/Cargo.toml

@@ -77,7 +77,19 @@ ed25519-dalek = { version = "=2.2.0", default-features = false, features = ["zer
 # stacks are isolated at the type level and never share state.
 ml-kem = { version = "=0.2.3", features = ["zeroize", "deterministic"] }
 kem = "=0.3.0-pre.0"
-ml-dsa = { version = "=0.1.0-rc.7", features = ["zeroize"] }
+# `default-features = false` drops ml-dsa's `pkcs8` and `rand_core` features.
+# soliton uses neither: keys and signatures cross the boundary as raw encodings
+# (B32, EncodedVerifyingKey, EncodedSignature), and keygen seeds `from_seed`
+# with bytes from soliton's own CSPRNG rather than a rand_core Rng.
+#
+# This is load-bearing, not tidiness. ml-dsa 0.1.0-rc.7 requires
+# `pkcs8 = "0.11.0-rc.10"`, which Cargo reads as `>=0.11.0-rc.10, <0.12.0` — so
+# once pkcs8 0.11.0 final shipped it outranked every rc and got selected, and
+# ml-dsa's `pkcs8.rs` stopped compiling (`?` cannot convert into the reshaped
+# `Error`). That broke a fresh `cargo add libsoliton`, since a library's
+# Cargo.lock does not constrain downstream resolution. With the feature off,
+# `pkcs8.rs` is never compiled and the breakage is unreachable.
+ml-dsa = { version = "=0.1.0-rc.7", default-features = false, features = ["zeroize", "alloc"] }
 # rand_core is pulled transitively by ml-kem (0.6) and ml-dsa (0.10).
 # Deterministic/seed-based APIs + getrandom are used to avoid RNG trait issues.
 
@@ -107,7 +119,9 @@ proptest = "=1.10.0"
 rayon = "=1.11.0"
 # ml-dsa is a direct dependency, re-declared here so integration tests can call
 # sign_internal directly to produce deterministic F.27 test vectors (pinned rnd).
-ml-dsa = { version = "=0.1.0-rc.7", features = ["zeroize"] }
+# Feature set must match the [dependencies] entry — see the note there for why
+# default features are off.
+ml-dsa = { version = "=0.1.0-rc.7", default-features = false, features = ["zeroize", "alloc"] }
 
 [[bench]]
 name = "bench"