Upgrade aes 0.8 -> 0.9 to drop the aes_armv8 cfg workaround

[coderdan]

Background

The crate currently depends on aes = 0.8.4 and ships a workaround so ARMv8
hardware AES is used on aarch64:

• .cargo/config.toml sets rustflags = ["--cfg", "aes_armv8"] for
  cfg(target_arch = "aarch64") (added in PR ORE v2 (3/n): efficient unary encoding + hardware AES on aarch64 #80),
• and packages/ore-rs/README.md tells downstream crates they must set the
  same flag in their own build config or they silently fall back to the ~60x
  slower software (fixslice) backend.

A code review of #80 flagged that this is fragile: rustflags in
.cargo/config.toml is silently ignored if a RUSTFLAGS env var is set
(common in CI/Docker/dev shells), so hardware AES can vanish with no error.

The fix: upgrade aes 0.8 → 0.9

aes 0.9 removes the aes_armv8 cfg entirely. The ARMv8 backend is now
#[cfg(all(target_arch = "aarch64", not(aes_backend = "soft")))] — enabled by
default, with runtime autodetection via cpufeatures on Linux/macOS
(CHANGELOG 0.9.0: "Enable ARMv8 backend by default", "Replace inline ASM with
ARMv8 intrinsics"). The opt-out is now --cfg aes_backend="soft".

Upgrading lets us:

• delete .cargo/config.toml's aes_armv8 rustflags,
• drop the downstream "set this flag too" caveat in the README,
• eliminate the RUSTFLAGS-override footgun,
• get hardware AES on aarch64 for downstream consumers automatically.

Scope / caveats (this is a breaking dep bump)

• MSRV: aes 0.9 ARMv8 intrinsics require Rust ≥ 1.61 (confirm our MSRV).
• API churn: 0.8→0.9 bumps the RustCrypto cipher trait generation; check
  Aes128::new / encrypt_block(s) / GenericArray usages in primitives/
  and the block-modes/other RustCrypto deps for version unification.
• zeroize feature: confirm aes 0.9 still exposes the zeroize feature
  and that aes::Aes128: ZeroizeOnDrop still holds — the ZA-0001 fix (fix(prp): zeroize Aes128Prng keystream on drop (ZA-0001) #84) adds
  a compile-time assert that depends on it, so the assert will catch a
  regression but we should expect it to still pass.
• Wire format: AES output is unchanged, so the pinned compat vectors must
  still pass byte-for-byte (good regression gate for the bump).

Acceptance

• aes bumped to 0.9.x; .cargo/config.toml aes_armv8 rustflags removed;
  README downstream-flag caveat removed.
• Hardware AES confirmed active on aarch64 without any flag (bench delta).
• cargo test (incl. compat vectors) + clippy -D warnings green.