Fix the build on modern Rust and stop advertising unimplementable AES-GCM suites

[DanGould]

main does not build on current Rust, and once it does, 11 of the crate's 23 tests fail. Two independent causes, one commit each. Neither needs a new bitcoin-hpke release, so this can land now.

Fix build on modern Rust after key-material redaction

PrivateKey's Debug impl still binds b from key_data() after the body changed to print [REDACTED], leaving it unused. This crate sets #![deny(warnings, clippy::pedantic)], so that is a hard error on current rustc. PublicKey's Debug still uses b and is untouched. Introduced in e275713.

Stop advertising the unimplementable AES-GCM suites

The AES-GCM symmetric suites were advertised but could never be used. bitcoin-hpke removed its AES-GCM schemes in 0.13.0 and dispatch_hpkes_new! only ever mapped ChaCha20Poly1305, so a peer that honoured the advertisement and selected AES-GCM got Err(InvalidKeyType). Config::supported() returned true for it regardless, and the test constants listed it first, which is why 11 of this crate's own tests failed.

Correcting supported() is enough. strip_unsupported then prunes the advertised KeyConfig automatically. The Aead enum keeps its GCM variants so other peers' configs still parse.

decode built its probe config with Aes128Gcm on the grounds that the KDF and AEAD did not matter there. They do now, since the probe is checked against supported(), so it uses ChaCha20Poly1305.

Two tests were stale from before the secp256k1 port and had never passed: derive_key_pair's expected config encoded a 32-byte X25519 key under KEM 0x0020, regenerated here for KEM 0x0016 with a 65-byte key; and truncate_kdf_aead_list hard-coded an offset assuming the X25519 key size, so it now derives the offset from the encoding.

This commit also clears two lints current clippy rejects under this crate's deny(warnings, clippy::pedantic): a redundant continue and non-inlined format args.

Behaviour change worth reviewing

Removing AES-GCM from the advertised set is wire-visible. A client selecting one of those suites previously got a runtime error; now it never sees them offered. Anything relying on the advertisement was already broken at use time, so this turns a runtime failure into an absent option rather than removing working functionality.

payjoin negotiates one suite, DHKEM(secp256k1) / HKDF-SHA256 / ChaCha20-Poly1305, so nothing on that path changes.

Verification

Against the published bitcoin-hpke 0.13.0, on current stable:

cargo test   -p bitcoin-ohttp --no-default-features --features rust-hpke,client,server
    22 passed, 0 failed
cargo clippy -p bitcoin-ohttp --tests --no-default-features --features rust-hpke,client,server -- -D warnings
    clean
cargo fmt --all -- --check --config imports_granularity=Crate
    clean

Scoped to -p bitcoin-ohttp deliberately: a workspace-wide run still fails in the sibling bhttp crate, which is a separate pre-existing problem tracked in #7 and is not a dependency of this crate.

What this does not fix

The 1.63.0 matrix leg fails before any of this crate's code is reached:

error: failed to parse manifest at `.../zeroize_derive-1.5.0/Cargo.toml`
error: failed to download `zeroize_derive v1.5.0`

That cargo cannot parse a modern dependency manifest, which no change here can address. It needs the MSRV decision in #6, and it fails identically on main.

The nss legs are untested locally; they need an NSS build.

Disclosure: co-authored by Claude Code.