Fix openssl panic due to missing iv

[malmeloo]

OpenSSL was causing a panic for me because the iv was missing in AES operations. This fixes that by manually setting the IV to the default constant value.

Not sure why that results in an error now but I guess something changed on OpenSSL's side.

[gregakespret]

+1 — reproduced today on macOS 26 with the Homebrew cargo 1.95.0 toolchain and openssl = 0.10.80. The exact panic point is Crypter::new(...) at src/util.rs:1591 (and the decrypt(...) call at :1621):

thread 'main' panicked at openssl/symm.rs:623:
an IV is required for this cipher

Easy public reproduction: any tool that drives rustpush through a PCS-encrypted CloudKit zone hits it on the first pcs_keys_for_record(...) call (the RFC 6637 unwrap path inside Crypter::new). The chain I hit it on:

• thisiscam/export-findmy → thisiscam/rustpush:findmy-export-support → this code → panics on the first BeaconStore record.

openssl 0.10.80 enforces an explicit IV for any cipher with non-zero iv_len() — passing None no longer falls through to the cipher's default. The fix here (the RFC 3394 §2.2.3.1 default constant 0xA6A6A6A6A6A6A6A6) is exactly what older openssl versions filled in internally, so the wire-level bytes are unchanged.

Any chance of a merge? Happy to test additional cases if useful. I had filed thisiscam/rustpush#1 before noticing this PR existed — closed it as a duplicate.