deps: RustCrypto stack split between 0.10 and 0.11 lines (turso/aes-gcm blocked) #1634

Context

The 2026-05-17 maintenance pass surfaced a persistent split in the workspace dependency tree across the RustCrypto stack:

Verified via cargo tree --workspace --duplicates after a clean cargo update.

Why this matters

Bigger binaries (two builds of every common hash primitive), and a real source of confusion when someone tries to audit which version of, e.g., sha2 actually backs a given API. Not a correctness issue today — neither line is unsound — but the longer it persists, the more likely subtle divergence between hash implementations becomes a debugging hazard.

Why it's blocked

Both 0.10-line consumers in the tree are pulled by upstreams we don't control:

1. turso_core 0.5.3 depends on aes-gcm 0.10.3 (which transitively brings aes, cipher, ctr, cpufeatures 0.2, crypto-common 0.1, and the 0.10 digest/sha* line). The dependabot config explicitly excludes turso_* from group bumps because turso is BETA upstream; latest is 0.7.0-pre.1.
2. aes-gcm 0.10.3 has not yet released a 0.11 line that targets RustCrypto's 0.11 cohort.

We can't unify locally — every workaround (patch-target overrides, vendored forks) costs more than the duplication.

What to track

• Watch RustCrypto/AEADs for aes-gcm 0.11.
• Watch tursodatabase/turso for a stable 0.7 or later that drops or replaces aes-gcm 0.10.
• Once either lands, run cargo update and confirm cargo tree --workspace --duplicates | grep -E '^(aes|sha[12]|digest|hmac|cipher|crypto-common|ctr) ' returns nothing.
• Update specs/maintenance.md deferred-items section when this is resolved.

Not in scope

• Replacing turso_core. Embedded SQLite via Turso is a core feature, not a candidate for swap.
• Adding [patch.crates-io] overrides. Maintenance burden outweighs the duplicated-build cost.

Surfaced during PR #1632 deep-maintenance pass.