deps: unify control-channel crypto on one RustCrypto generation (LAN-582)

[lance0]

Takes the chacha20poly1305 0.10 → 0.11 and hkdf 0.12 → 0.13 bumps that were split out of the last dependency refresh, and removes the reason they were stuck.

Why it was blocked

src/control_crypto.rs sat on the crypto-common 0.1 generation (chacha20poly1305 0.10, hkdf 0.12) and carried its own renamed copies of sha2 0.10 and hmac 0.12 to match — while src/auth.rs had already moved to sha2 0.11 / hmac 0.13 on the digest 0.11 generation. Bumping just the AEAD pair drags in digest 0.11 types that can't meet the 0.1-generation bounds, which is why #144 (and now #149) fails every job.

What changed

• chacha20poly1305 0.11, hkdf 0.13; the renamed sha2_010 / hmac_012 dependencies are deleted, so control crypto now shares sha2 0.11 / hmac 0.13 with PSK auth.
• One source change beyond the imports: new_from_slice moved from Mac to KeyInit in hmac 0.13, and chacha20poly1305::KeyInit is also in scope in that module, so the call is fully qualified.
• The host build no longer compiles two generations of crypto-common / digest / block-buffer (cargo tree -i digest@0.10.7 now reports nothing).

Interop

The wire format is unchanged, and this is worth being sure about rather than assuming — the protected control channel has to keep talking to older peers.

• Fixed vectors. New test wire_bytes_match_v0_9_22_vectors pins the three derived keys, two sealed frames from one codec (seq 0 and seq 1, so nonce and AAD derivation are covered too), the same plaintext sealed in the other direction, and the server proof. The values were captured by running the same inputs through the pre-port crate versions; they pass unchanged on the new ones. The existing tests all seal and open with the same code, so they'd have passed on a silently-changed KDF — this one wouldn't.
• Live cross-version runs. PSK-protected tests, old server ↔ new client and new server ↔ old client, both complete clean; a wrong-PSK run against the ported server is still rejected. With PSK active the server installs the AEAD transport unconditionally after auth, so every post-auth control message in those runs went through seal/open across the version boundary.

Also validated: cargo fmt --check, clippy -D warnings and the full test suite in both --all-features and --no-default-features.

Supersedes #149.

Closes LAN-582