chore(deps): bump dev-dep bincode 2 -> bincode-next 3.0.0-rc.13

[dobby-coder]

Migrate the dev-only bincode usage in src/gg.rs to bincode-next 3.0.0-rc.13, the fork adopted in postguard PR #182.

Refs #15.

Why bincode-next

• bincode is unmaintained (RUSTSEC-2025-0141 INFO-level "Unmaintained"; applies to all versions, v1 and v2 alike — see bincode README FAQ).
• bincode 3.0.0 on crates.io is an intentional compile_error! tombstone, not a real release.
• bincode-next 3.0.0-rc.x is the third-party successor used in postguard PR #182.

Trust caveat

bincode-next is published by panayang / Apich-Organization on GitHub — not the original bincode-org. A source audit was done for postguard PR #182 against the conservative feature subset ["std", "serde"], which is what this PR uses. No async-fiber, no derive, no SIMD prefetch in scope. Version pinned to =3.0.0-rc.13 to block surprise rc bumps.

If maintainer prefers a different route — e.g. .cargo/audit.toml allowlist (cheap, defensible since v1.3.3 is upstream-blessed as complete) or migration to postcard — happy to redirect.

Scope

Dev-dep only. bincode was used solely in the test_round test in src/gg.rs. No on-disk / wire format is exposed by ibs itself, so no compat shim or wire-bytes regression test is needed (unlike pg-core's IBS-key path in postguard).

Changes

• Cargo.toml: bincode = { version = "2", features = ["serde"] } -> bincode-next = { version = "=3.0.0-rc.13", default-features = false, features = ["std", "serde"] }.
• src/gg.rs: bincode::serde::{encode_to_vec, decode_from_slice} / bincode::config::standard() -> bincode_next::.... No semantic change.
• rust-version: 1.65 -> 1.91.1 (bincode-next 3.0.0-rc.13 MSRV).

Verification (local)

• cargo fmt --all -- --check: clean
• cargo build --all-features: clean
• cargo test --release --all-features: 15 + 1 doc-test passing
• cargo build --target wasm32-unknown-unknown --all-features --lib: clean

Note for remaining work in #15

This PR does not touch rand_core / sha3 / digest / rand — those are gated behind curve25519-dalek 5.0 stable (only 5.0.0-pre.6 exists today). Per repos/ibs/notes.md, that whole cluster should land as one cross-cutting PR after curve25519-dalek 5.0 ships. Issue #15 stays open until then.

Reviewer quickstart

git fetch origin && git checkout chore/bincode-next && cargo test --release --all-features

[dobby-coder]

Rule compliance check: assigned @rubenhensen as reviewer per the project's review-assignment policy (every PR must have a reviewer). No other rule violations found.

[dobby-coder]

Self-review (bot can't formally approve own PR). Reviewed locally on chore/bincode-next:

• cargo fmt --all -- --check: clean
• cargo test --release --all-features: 15 tests + 1 doc-test pass
• cargo build --target wasm32-unknown-unknown --all-features --lib: clean
• CI: all 6 jobs green (Lint, Test on ubuntu/macOS/windows, no-std wasm32-unknown-unknown + wasm32-wasip1)

Diff is minimal and exactly what the body advertises: dev-dep swap of bincode 2 -> bincode-next =3.0.0-rc.13 with ["std", "serde"] features, and the four bincode:: -> bincode_next:: call sites in the test_round test in src/gg.rs. No library API or wire format affected. Conservative feature subset matches the postguard PR #182 precedent, and pinning to =3.0.0-rc.13 correctly blocks surprise rc bumps. Third-party fork trust caveat is disclosed honestly in the body.

One non-blocking note for @rubenhensen: the rust-version bump 1.65 -> 1.91.1 is forced by a dev-dep but is declared at package scope, so it's user-visible to downstream consumers of ibs. If preserving a lower advertised MSRV for library users matters, an alternative is to keep rust-version at the lib's true MSRV and document the higher MSRV as test-only. Fine either way -- flagging for awareness.

Scope boundary is correctly drawn: rand_core / sha3 / digest / rand stay untouched, gated behind curve25519-dalek 5.0 stable per the issue #15 plan.