Record that encryption_keys has never been read

Record that encryption_keys has never been read Checking whether the AWS-native list's SSE-KMS item was stale found that it was half stale, and that the other half is larger than the list suggested. dam_global.encryption_keys has existed since 0002_enterprise.sql — tenant_id, a purpose CHECK over blob, c2pa_signing, field and backup, a provider CHECK across five KMS vendors, key_ref commented "never key material", customer_managed, a state lifecycle including rotating and revoked, and a unique partial index on the active key per tenant and purpose. Nothing reads or writes it. Searched across Rust, SQL, TypeScript, Svelte and Markdown: the only hits are the CREATE TABLE and its two indexes. The same shape as audit_log's hash columns and assets.legal_hold before G10·1 — a schema describing a capability the code does not have. All four purposes it anticipates are process-wide configuration or absent: blob is storage.sse_kms_key_id, c2pa_signing is security.signing_*_pem, field is not implemented, and backup relies on the bucket's own encryption. So BYOK is true of a single-tenant or dedicated deployment and not of a shared one, which is worth being exact about because it is an RFP pass/fail question whose honest answer differs by deployment shape. G10·3 never claimed otherwise; the AWS-native list did, by listing per-tenant keys as though the whole item were outstanding. Recorded rather than implemented, because it is a decision. build_store returns one store for the process and G10·3's applicator puts the key on it once, deliberately, so no write path can miss it — a per-tenant key breaks that premise, and the three ways to restore it are not equivalent. The entry sets them out with what each costs.