fix(crypto): bump libsodium wrappers for ESM imports

[Chris79OG]

Summary

• bump @cardano-sdk/crypto from libsodium-wrappers-sumo@0.7.10 to ^0.8.4
• refresh the Yarn/Nix lock entries for libsodium-wrappers-sumo and libsodium-sumo
• pass an explicit null key to crypto_generichash so the package builds against the 0.8 bundled types

Verification

• node .yarn/releases/yarn-3.2.1.cjs install --mode=skip-build
• node .yarn/releases/yarn-3.2.1.cjs workspace @cardano-sdk/crypto exec tsc --build src
• node .yarn/releases/yarn-3.2.1.cjs workspace @cardano-sdk/crypto exec tsc -p src/tsconfig.json --outDir ./dist/esm --module es2020 --noEmit
• node -e "import('libsodium-wrappers-sumo').then(async m => { const s=m.default||m; await s.ready; const h=s.crypto_generichash(28, new Uint8Array([1,2,3]), null); console.log(h.length === 28 ? 'hash ok' : 'bad length '+h.length) })"

Note: yarn workspace @cardano-sdk/crypto build reaches the TypeScript build, then fails on Windows because the package script uses Unix cp.

Closes #1682

[AngelCastilloB]

Thanks @Chris79OG , we need to audit the new package version before we can merge this, cc @rhyslbw

[rhyslbw]

Audit: libsodium-wrappers-sumo 0.7.10 → 0.8.4

Ran a two-pass audit (static review + tarball/runtime inspection). Clean, narrowly-scoped fix for a real ESM-loader bug (#1682), against a dep with a single trusted maintainer, with byte-identical crypto outputs at the SDK's hash/sign call sites. Small change request to pin the version exactly, otherwise good to merge.

Provenance

• Same npm publisher across all 0.7.x and 0.8.x versions: jedisct1 (Frank Denis, author of upstream libsodium-C). No ownership change.
• All five 0.8.x tarballs are npm-signed with the same key (SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U); the keyid delta vs 0.7.10 is npm's own registry signing-key rotation, not a user-controlled change.
• 7 distinct upstream contributors between tags 0.7.10 and 0.8.4 (163 commits), all real-named; every non-jedisct1 PR was reviewed and merged by Frank Denis. Sampled non-maintainer diffs match their commit messages.

Tarball contents

• Both libsodium-wrappers-sumo@0.8.4 and libsodium-sumo@0.8.4 contain only package.json, README.md, LICENSE, and four JS/dts files. No scripts field, no pre/post-install hooks, no native blobs (.node/.so/.dylib), no bin entries.
• Only network/eval-adjacent strings are canonical Emscripten boilerplate (require("crypto") for Node randomBytes fallback; XMLHttpRequest/fetch in the wasm/asm.js loader). Zero eval(), new Function(), or child_process.
• No transitive surface expansion — libsodium-sumo remains the only runtime dep, same as 0.7.10.

Vulnerabilities

• OSV reports no advisories for either libsodium-wrappers-sumo or libsodium-sumo at any version.

Crypto correctness (the part that matters for a key-derivation/signing dep)

• Bundled native libsodium in 0.8.4 is 1.0.22-RELEASE (legitimate latest upstream, signed by jedisct1).
• crypto_generichash symbol diff between 0.7.10 and 0.8.4: only change is hash_length typing uint → ranged_uint (stricter input validation; identical underlying C call). crypto_generichash(28, pk) and crypto_generichash(28, pk, null) produce bit-identical 28-byte output — the null arg is libsodium's canonical "unkeyed BLAKE2b" sentinel.
• Verified known-answer vectors against 0.8.4: BLAKE2b-256(empty) = 0e5751c0…12fe3a8, BLAKE2b-256("abc") = bddd813c…8d52319, Ed25519 RFC 8032 seed-1 keypair and detached signature both byte-match the spec.
• All other sodium symbols packages/crypto/src imports (crypto_scalarmult_ed25519_base_noclamp, crypto_core_ed25519_*, crypto_hash_sha512, crypto_sign_seed_keypair, crypto_sign_detached, crypto_sign_verify_detached, crypto_auth_hmacsha512) remain call-compatible with current usage — no other source changes required.

[AngelCastilloB]

I pulled the 0.8.4 tarballs and checked their SHA-512 hashes against what the registry reports, both matched exactly, and npm's own signature on the packages verified. I also re-ran our own yarn to recompute the lockfile checksums from a fresh download, and they matched the values in yarn.lock and yarn-project.nix byte-for-byte.