Implement Field Encryption Utilities

Use the envelope encryption pattern: generate a random DEK per contact record (or per field group), encrypt the DEK with the Vault master key (Vault stores and manages the master key — you never see it), store the encrypted DEK alongside the ciphertext. On decryption, send the encrypted DEK to Vault for unwrapping, then use the unwrapped DEK locally for AES-GCM decryption. Use pointycastle's GCMBlockCipher for AES-256-GCM. Cache the unwrapped DEK in a private in-memory map keyed by contact_id, invalidated on Flutter AppLifecycleState.paused.

The read-receipt hook should be a separate FieldReadReceiptService that is called from the decryption utility via a callback or post-decryption hook — keep it decoupled so it can be mocked independently. For key rotation, add a key_version field to the encrypted payload DTO; the decrypt path reads this version and fetches the appropriate Vault key by version ID. Consider a Supabase RPC function for read-receipt writes to enforce server-side validation (prevents clients from spoofing user IDs).

Unit tests for the AES-GCM encrypt/decrypt cycle using pointycastle directly (no Vault dependency). Integration tests against Supabase Vault staging: verify encrypt → store → retrieve → decrypt round-trip, verify tampered ciphertext is rejected (GCM tag failure), verify key rotation (encrypt with v1, rotate to v2, verify v1 ciphertext still decrypts, new encryptions use v2). Test read-receipt writes: mock Supabase client and verify fire-and-forget call is made after successful decryption. Test that read-receipt failure does NOT throw.

Test DEK cache invalidation on simulated app background event. Run all sensitive data tests in an isolated test environment with no real PII.