#21: fix the DKIM, onboarding and console defects found reviewing the new work

DKIM rotation broke the domain it was run on. It retired the live key and
inserted a placeholder as ACTIVE - private_key_enc was the literal string
"dummy-encrypted-key" - so FindActiveKeys then failed for the whole
domain and outbound mail stopped being signed, with the real key already
gone. Reproduced against a database before changing anything.

The root cause runs deeper: the auth service derives its encryption key
with a plain SHA-256 of the master key while the protocols service uses
HKDF with its own info string, so nothing the auth service seals can ever
be opened by the signer. Rotation therefore moves to the protocols
service, which owns that vault and the real key generator. It retires the
previous key with a seven-day overlap in the same transaction rather than
deleting it, because mail already sent under it is still being verified.

Domain onboarding had three defects in one function. It built the alias
destination by interpolating the domain name into the SQL text, which was
injectable; it reused one placeholder for a CITEXT and a VARCHAR column,
which made the statement fail and happened to hide the injection; and it
ignored its scope argument entirely, so any DOMAIN_ADMIN could create
domains. It also provisioned postmaster, abuse and security, missing the
dmarc and tlsrpt aliases that the published records point at - PLAN.md
section 7.4b is explicit that reports bounce without them.

The TLS panel returned fixed values: acme_status "VALID" and 72 days to
expiry, whatever the process actually held. It now reads the certificate
watcher, and a compile-time assertion keeps the wiring from silently
regressing into "disabled". The audit log and the readiness scorecard were
fixtures too, and their field names did not match the API they now read.

Two tests failed and a third asserted a fabricated constant: one depended
on test order through a shared fixture that had a second factor enrolled,
one used a fixed domain name and so passed once per database, and one
expected "records: 13" from a function that never touches DNS. All three
are fixed, and the suite now passes twice in a row against one database.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

services/auth/vitest.config.ts

@@ -1,5 +1,13 @@
 import { defineConfig } from "vitest/config";
 
 export default defineConfig({
-  test: { environment: "node" },
+  test: {
+    // session.ts refuses to load without a real signing secret, and ESM hoists
+    // imports - so the value has to exist before any test file is evaluated,
+    // which an assignment inside a test file cannot guarantee.
+    env: {
+      JWT_SECRET: process.env.JWT_SECRET ?? "a-test-signing-secret-long-enough-for-the-guard",
+      LAMBDAMAIL_MASTER_KEY: process.env.LAMBDAMAIL_MASTER_KEY ?? "test-master-key-at-least-16-chars",
+    },
+  },
 });