fix(cggmp24): don't panic on out-of-range signer index in validate_consistency

[Joshuaisikah]

Fixes #201

DirtyKeyShare::validate_consistency (in cggmp24/src/key_share.rs) indexed aux.N[usize::from(core.i)] directly. Both current callers only ever pass a core that's already been through is_valid() (or is a Valid<_> by type), so core.i is in range in practice today. But validate_consistency itself has no way to enforce that on its own — it's relying entirely on caller discipline, and a future caller (or a refactor that reorders the existing checks) could trivially reintroduce a panic here.

Changes

• Replace the direct index with .get(usize::from(core.i)).ok_or(InvalidKeyShareReason::PartyIndexOutOfBounds)?
• Add the PartyIndexOutOfBounds error variant
• Add a regression test (validate_consistency_rejects_out_of_range_signer_index) that calls validate_consistency directly with a deliberately out-of-range core.i, bypassing the public API's guards, to prove the function is safe on its own rather than relying on the invariant its callers happen to uphold today. Verified locally that this test panics against the old code (index out of bounds: the len is 2 but the index is 5) and passes cleanly against the fix.

I also checked key-share/src/valid.rs, per the issue's hedge that "the similar problem may be present" there too — I didn't find any unguarded indexing in that file, so no changes were needed there.

Testing

cargo test -p cggmp24 --features all-curves,hd-wallet,spof
cargo clippy -p cggmp24 --features all-curves,hd-wallet,spof --lib -- --no-deps -D clippy::all -D clippy::unwrap_used -D clippy::expect_used
cargo fmt --check -p cggmp24

All pass.