Envelope encryption primitives land; nothing uses them yet

easterbrooka added the full cryptography layer for envelope-encrypted API keys and workflow shares - KMS wrapper, AES-256-GCM envelope, HMAC email lookup - without wiring any of it into the running backend. The split is deliberate: call-site changes come in a follow-up PR.

The data model gains a per-tenant DEK table with one active wrapped data-encryption-key per user, plus ciphertext columns added alongside the existing plaintext fields for Claude and Gemini API keys and for workflow share recipients. Workflow shares also get an HMAC column with a unique index, preserving the share-uniqueness invariant through the eventual dual-write window. The old plaintext columns stay in place until a later migration removes them after the ciphertext path is verified in production.

The crypto envelope is AES-256-GCM with a self-describing layout: a version byte, DEK id, IV, ciphertext, and tag. The version byte is checked on every open; a v2 slot is reserved for AAD binding later. Deterministic email lookup uses HMAC-SHA256 with a pepper stored in Secrets Manager rather than the database. A process-local LRU caches decrypted DEKs by id so KMS Decrypt is only called once per DEK per process.

easterbrooka is explicit about the threat model: this defends against a database-only breach - a leaked Supabase dump, a rogue read replica, a compromised storage backup. A leaked service-role key still bypasses RLS and constitutes a full compromise; that's out of scope here. Forty-one unit tests ship with the primitives, the suite holds at 86/86, and the AWS-side setup - KEK alias, HMAC pepper secret, backfill script, call-site rewiring, and eventual plaintext column drop - is documented and deferred to named follow-ups.