Byte-injective transcript sponge adapter

Summary

The Poseidon2 and Skyscraper duplex-sponge adapters decode each 32-byte lane via from_le_bytes_mod_order (or equivalent). This reduces lane values ≥ p mod p, so the bytes → Fr → bytes round-trip is only byte-injective when every absorbed lane is already < p.

All absorb sites write canonical encodings:

• Field elements serialized via field_to_bytes_le (always < p by construction)
• WHIR engine outputs (themselves canonical field elements)
• ASCII domain-separator bytes (every byte < 0x80, so any 32-byte lane is trivially < p)

Why it's fragile

Nothing at the sponge layer enforces this invariant. spongefish::DuplexSponge::absorb takes &[u8] and writes raw bytes straight into permutation_state — the Permutation::permute impl has no way to reject non-canonical input.

Any of the following would silently break byte-injectivity:

• A raw SHA-256 / Keccak-256 digest (~25% of outputs ≥ p)
• 32 bytes from a randomness beacon or /dev/urandom
• A non-ASCII DS that lands above 0x80 in the MSB of a lane

Affected files

• provekit/common/src/poseidon2/sponge.rs
• provekit/common/src/skyscraper/sponge.rs

Both sponges share the same adapter (utils::bytes_to_field / utils::field_to_bytes_le)

Read provekit/common/src/poseidon2/sponge.rs and provekit/common/src/skyscraper/sponge.rs, then trace their shared utils::bytes_to_field and utils::field_to_bytes_le adapters. Check each absorb path and how non-canonical 32-byte lanes are handled. Done should preserve byte-injectivity for accepted inputs, with coverage for lanes at or above the field modulus, although the issue does not specify the intended handling strategy.