aead: expose typed header-protection masks

[loadingalias]

Summary

• add expert-only typed AES-128, AES-256, and ChaCha20 header-protection key/context APIs without coupling rscrypto to a protocol
• reuse the native AES-NI, AES-CE, and portable dispatch boundary while keeping the portable implementation authoritative
• zeroize owned key material, redact diagnostics, and add the new surfaces to constant-time and secret-lifecycle evidence
• add RFC 9001/FIPS vectors, independent differential tests, fuzz coverage, WASI runtime vectors, and representative benchmarks

Security and performance

The API fixes key and sample sizes in the type system, exposes only the five-byte mask, and keeps raw primitive mechanics under the existing expert capability boundary. AES key schedules and ChaCha20 keys are cleared on drop, with compiler-level zeroization evidence. The implementation does not introduce protocol-specific names or behavior.

Measured AArch64 and x86_64 results show the native rscrypto paths materially ahead of the equivalent RustCrypto header-protection work; the benchmark catalog records the workloads without extending claims beyond measured targets.

Focused validation

• cargo clippy --locked --no-default-features --features aes-gcm,chacha20poly1305,aegis256 --lib --tests -- -D warnings
• cargo clippy --locked --target x86_64-unknown-linux-gnu --no-default-features --features aes-gcm,chacha20poly1305 --lib -- -D warnings
• cargo test --locked --no-default-features --features aes-gcm,chacha20poly1305,aegis256 --lib --test header_protection --test secret_redaction
• just ct-validate --target aarch64-apple-darwin --manifest-only
• just check-zeroize-evidence
• scripts/ci/nostd-wasm-suite.sh wasm32-wasip1 shallow