GeezerVison

Part of CODAGT-1135.

Stacked on #32067. Review only this diff. It merges after #32067.

Why

Chat automations store a webhook secret in chat_automations.webhook_secret. dbcrypt encrypts only in the methods it overrides, so a writer without an override would store the secret in plaintext and nothing would encrypt it later. This PR makes the database layer encrypt the secret before any code writes one. As the RFC says, dbcrypt encrypts the column when the deployment sets --external-token-encryption-keys. Without keys the column holds plaintext, as it does for external auth tokens today.

What changed

• InsertChatAutomation encrypts the secret and sets webhook_secret_key_id. GetChatAutomationByID decrypts it. This replaces the fail-closed stub that feat: add the chat automations schema and RBAC resource #32067 added. The list query still returns no secret.
• dbcrypt rotate, decrypt and delete cover the column. Two new queries serve only these commands (system actor in dbauthz). delete blanks the secret to the empty string and keeps the row, because a webhook row must hold a secret.
• A test fails with the method name when a database.Store method takes or returns a WebhookSecret, or its query names the column, and dbCrypt has no override of that name. A later update or rotate query cannot forget its override.
• The "malformed encrypted field" decrypt error no longer quotes the stored value. A plaintext secret under a key ID would have ended up in the error text. This is its own commit and touches every encrypted column.
• One line in the docs list of encrypted columns.

Scope

No handler, API type or writer of the secret. A NULL or empty secret is not encrypted: it keeps a NULL key ID and rotation skips it, like AI provider keys.

Tradeoffs

• rotate and decrypt handle a user's automations in the existing per-user transaction. If coderd rewrites a secret after the command read the row and before the command writes it, the transaction fails and the command stops with an error. A rerun works. If the command writes first, coderd's write lands after the commit. In both orders the command never writes a stale secret back. The commands never change webhook_secret_version.
• dbcrypt delete leaves webhook automations enabled with an empty secret. A request must never verify against an empty secret, so the webhook route has to reject it.
• A replica that was already running without keys when the first key appeared stores new secrets in plaintext with a NULL key ID, as for every dbcrypt column. It cannot read a secret that a keyed replica wrote and returns a decrypt error. A replica that starts without keys while a key is active refuses to start. The plaintext rows stay plaintext until every replica has the keys and dbcrypt rotate has run.

Live check

On a local Enterprise build with keys set, a webhook row inserted through the dbcrypt store left no plaintext in the raw column. dbcrypt rotate, decrypt and delete then ran against that database and ended as intended. On a database that a running coderd has used, rotate stops at the key revoke because of crypto_keys rows. That gap is older than this PR (#25381).

Generated with xum • Model: anthropic:claude-sonnet-5-5 • Thinking: xhigh