release: 0.8.3 — client dependency-range refresh (ramqp 0.8.3 + ramqp-core 0.2.6)

[mack42]

Follow-up to the latest-stable audit of the client crates. Two deps were held back by manifest ranges; this bumps them and cuts a client release.

Changes

• base64 0.22 → 0.23 (ramqp scram feature + ramqp-core scram feature)
• tokio-tungstenite 0.29 → 0.30 (ramqp ws feature, dev-dep, and dev-only bench-compare) — also removes the duplicate sha1 0.10 that tungstenite 0.29 dragged in next to the SCRAM stack's sha1 0.11
• Versions: ramqp 0.8.3, ramqp-core 0.2.6; core pin synced in both dependents (ramqp, ramqp-broker) per RELEASING.md. ramqp-broker stays 0.9.2 (^0.2.5 already accepts 0.2.6 — pin sync only, no republish needed).
• CHANGELOG dated 2026-07-31; README crate-status refreshed.
• No code or API changes (public API compile-locked by tests/public_api.rs).

Verification (all on the bumped deps)

• cargo test --all-features: all 23 test binaries green.
• cargo clippy --all-targets --all-features -- -D warnings: clean.
• Live RabbitMQ 4.3.1: 6/6 tests/broker.rs interop + ws_roundtrip_via_bridge (exercises tungstenite 0.30 on both client and bridge sides).
• cargo publish -p ramqp-core --dry-run: passes. ramqp dry-run fails only on the index lookup for unpublished core 0.2.6 (expected per RELEASING.md).
• Every other client dep verified at latest stable against the crates.io index (rustls 0.23.43, tokio 1.53.1, bytes 1.12.1, uuid 1.24.0, sha2 0.11, hmac 0.13, pbkdf2 0.13, …).

After merge: tag v0.8.3 on the merge commit → release.yml publishes ramqp-core 0.2.6 → index wait → ramqp 0.8.3 (broker step no-ops as "already exists") → GitHub release.