fix: make Hash duplex sponge portable across pointer widths

[shreyas-londhe]

Problem

Hash<D> (the Digest-bridge duplex sponge backing Blake2b512, Blake2s256, SHA256, SHA512) folds two counters into the hash state at native pointer width:

• squeeze, Mode::Squeeze(i) branch — Digest::update(&mut output_hasher_prefix, i.to_be_bytes()), i: usize
• squeeze_end — Digest::update(&mut squeeze_hasher, byte_count.to_be_bytes()), byte_count: usize

usize::to_be_bytes() is 8 bytes on 64-bit targets and 4 bytes on 32-bit (e.g. wasm32). The first squeeze hits Mode::Squeeze(0) → 0usize.to_be_bytes() is 8 zero bytes vs 4, so the squeezed output diverges from the first byte.

Impact

Any protocol where a 64-bit prover produces a transcript/NARG that a 32-bit verifier replays (in-browser/on-chain wasm32 verifiers, 32-bit embedded) derives different Fiat-Shamir challenges, so verification fails. Found verifying a 64-bit-produced transcript inside a wasm32 verifier: a 7-byte-absorb-then-squeeze probe diverged between native and wasm; with this patch the probe, all derived challenges, and full proof verification match native exactly.

The permutation-based DuplexSponge<P, …> (Keccak, Ascon) is not affected — its usize fields (absorb_pos/squeeze_pos) are buffer indices and are never absorbed.

Fix

Encode both counters as fixed-width u64:

Digest::update(&mut output_hasher_prefix, (i as u64).to_be_bytes());
// …
Digest::update(&mut squeeze_hasher, (byte_count as u64).to_be_bytes());

On 64-bit this is byte-identical to the current output (i as u64 == i for usize), so existing transcripts and the spec vectors (duplexSpongeVectors.json, test_shosha) are unchanged — confirmed by the existing suite passing. Only 32-bit output changes, now matching 64-bit. Since 32-bit verification is currently broken, there is no compatible 32-bit consumer to break.

On testing

I deliberately did not add a unit test, because a regression here is undetectable on a 64-bit-only CI: the buggy usize and the fixed u64 encodings are byte-identical on 64-bit (same value, same type), so no runtime assertion can distinguish them. The property is only observable on a 32-bit target.

The right guard is a 32-bit CI lane (e.g. i686-unknown-linux-gnu, or wasm32 with a test runner) running the existing suite — the current multi-block-squeeze vectors (test_shosha, duplexSpongeVectors.json) already exercise the Mode::Squeeze(i) counter and would catch any pointer-width divergence for free. The CI currently has no such lane (wasm32-unknown-unknown also needs a getrandom backend for the dev-deps). Happy to add an i686 test job in this PR if you'd like that guard.

[mmaker]

approving, adding more regression guards