feat(encryption) [5/N] Support encryption: Encryption Manager

[xanderbailey]

Which issue does this PR close?

Part of #2034

What changes are included in this PR?

Stacked on #2340. Adds EncryptionManager — handles two-layer envelope encryption (master key → KEK → DEK) for Iceberg tables.

New files

• encryption_manager.rs — EncryptionManager with typed_builder construction:
  • encrypt() / decrypt() — AGS1 stream file encryption
  • generate_native_key_metadata() — generates StandardKeyMetadata (DEK + AAD prefix) for Parquet Modular Encryption (PME). Callers pass this directly to the Parquet writer's FileEncryptionProperties and serialize it for manifest storage.
  • wrap_key_metadata() / unwrap_key_metadata() — KEK envelope wrapping for manifest list key metadata
  • KEK lifecycle: creation, rotation (730-day NIST SP 800-57 lifespan), caching (1-hour TTL via moka)
• encrypted_io.rs — EncryptedInputFile, EncryptedOutputFile wrappers for transparent AGS1 stream encrypt/decrypt on read/write

Design decisions

• No NativeEncryptedInputFile / NativeEncryptedOutputFile wrappers — For PME, StandardKeyMetadata already carries the DEK and AAD prefix. Wrapper types that just bundle an InputFile/OutputFile with the same data are unnecessary indirection. Readers deserialize StandardKeyMetadata directly from key_metadata bytes; writers receive (OutputFile, &StandardKeyMetadata) separately.
• generate_native_key_metadata() is sync — unlike AGS1 encryption, PME key generation doesn't touch KMS. It just generates random bytes locally.

How this differs from Java's StandardEncryptionManager

• KEK management is explicit: Java's addManifestListKeyMetadata() mutates an internal map and callers need to downcast to StandardEncryptionManager to access the keys. Our wrap_key_metadata() returns (wrapped_key, Option<new_kek>) directly. no hidden mutation, no downcasting. Java
• No EncryptionUtil grab-bag: Java needs a static utility class (decryptManifestListKeyMetadata, encryptManifestListKeyMetadata, etc.) because the interface is too narrow. Here those are just methods on EncryptionManager.
• table_key_id enforced at compile time: Required via typed_builder, can't forget it. Unencrypted tables use Option<EncryptionManager> instead of Java's PlaintextEncryptionManager.
• Config values match Java exactly: KEK lifespan (730 days), cache TTL (1 hour), AAD prefix length (16 bytes) are all hardcoded.

Notes on usage for how this is used:
load_manifest_list does:

                let unwrapped_km = em
                    .unwrap_key_metadata(encrypted_key, table_metadata.encryption_keys_map())
                    .await?;
                let input = file_io.new_input(&self.manifest_list)?;
                em.decrypt(input, &unwrapped_km).await?.read().await?

load_manifest does:

        let avro = match &self.key_metadata {
            Some(km) if !km.is_empty() => {
                let em = encryption_manager.ok_or_else(|| {
                    Error::new(
                        ErrorKind::FeatureUnsupported,
                        "Encrypted manifest but no EncryptionManager configured on table",
                    )
                })?;
                let input = file_io.new_input(&self.manifest_path)?;
                em.decrypt(input, km).await?.read().await?
            }
            _ => file_io.new_input(&self.manifest_path)?.read().await?,
        };

        let (metadata, mut entries) = Manifest::try_from_avro_bytes(&avro)?;

Are these changes tested?

Yes

[xanderbailey]

Put a cache here for the same reason Java does, KMS is not aware of the key_id and since we populate the cache when we create_kek it would be hard to do this purely within a CachingKmsService