docs(server): design gateway_credentials at-rest encryption + server_secrets store (RIG-2863)

docs/designs/DECISIONS.md

@@ -112,6 +112,8 @@ check enforces the mechanical half. Full rationale:
 | DL-314 | Postgres remains the store of record and the sole durability source of truth for committed comms/routing/session-binding state (restating DL-019's surviving "Postgres is the store of record" clause verbatim): JetStream is an at-least-once delivery TRANSPORT whose consumer state is disposable, never a second truth store; every fabric recovery path terminates in a Postgres cursor or row. Supersedes DL-019's "JetStream is comms-only" clause only — its store-of-record and transcript-blob-seam clauses (DL-093) survive (RIG-2861 OQ-1) | Active (Matt, 2026-08-31) | [multi-tenancy & NATS substrate](infra/runtime/compass-managed-multitenancy/design.md#q3--the-eventing-substrate-one-nats-eventfabric-a-standalone-stack-service-jetstream-as-the-delivery-transport) |
 | DL-315 | The cross-tenant background/system loops (delivery-cursor sweep, deliver-ack advance, reattach recovery, lag-resync) run under a narrowly-scoped `BYPASSRLS` system role granted ONLY to those named background workers and NEVER on the request path; every request-path query stays fail-closed under RLS (RIG-2861 OQ-4 = option 1) | Active (Matt, 2026-08-31) | [multi-tenancy & NATS substrate](infra/runtime/compass-managed-multitenancy/design.md#resolved-decisions-freeze--matt-2026-08-31) |
 | DL-317 | Under multi-tenancy, user/system handle uniqueness is PER-ORGANIZATION not global (RIG-2921 = option A): `account_handles` gains a `tenant_id` and its partial-unique indexes become org-scoped, and the handle resolvers gain a tenant filter — two organizations may each hold `@matt`. The sole globally-unique identifier is the organization NAME, CASE-FOLDED for that uniqueness check (normalized index form, display casing preserved) — `Acme` and `acme` are the same organization (GitHub model). Refines DL-271's "user/system handles globally unique" clause to per-organization under multi-tenancy (single-tenant OSS stays degenerate: one org, so per-org == global); implemented on the RIG-2880 `account_handles` storage contract | Active (Matt, 2026-08-31) | [multi-tenancy & NATS substrate](infra/runtime/compass-managed-multitenancy/design.md#resolved-decisions-freeze--matt-2026-08-31) |
+| DL-325 | The `gateway_credentials` value payload is encrypted at rest application-side (AES-256-GCM envelope; `value_ciphertext`+`value_nonce`+`key_version` columns, no plaintext column ever; AAD binds the stable row identity so ciphertexts are not row-portable), covering api_key and OAuth rows on ONE seal/open path (D7). A 256-bit master key is auto-provisioned zero-human-step into the ONE configured SecretSpec provider under a Postgres advisory lock with every-boot read-back verify (+ a key-fingerprint tripwire). The master key and the existing server secrets (primary + reviewer App PEM, webhook, and the three Linear secrets) live in a NEW physically separate `server_secrets` store (mechanism C1: names-only table, bucket-A infrastructure — no `tenant_id`, RLS off, its own GRANT to `compass_app`/`compass_system`; no delivery/kind columns; a SECOND `SpecResolver` instance over it on the shared profile; an admin-gated `SetServerSecret`/`DeleteServerSecret` RPC) so server secrets are STRUCTURALLY undeliverable to agent containers — the container resolver's manifest never contains their names. C1 splits the DECLARATION registries, not the shared provider keyspace, so TWO guards are MANDATORY on BOTH the admin RPC AND the `authenticatedOpen` user `SetSecret`/`DeleteSecret` path: the reserved-name guard on `GATEWAY_CREDENTIALS_*`, and — because the other six names are arbitrary per-deployment config with no reserved prefix — a SYMMETRIC F1 membership guard rejecting any name present in the other table (in both declaration orders). The table split alone is necessary but not sufficient for the structural claim. No proto ENUM change and no FetchSecrets filter — the admin RPC adds two additive SecretsService methods (supersedes the earlier SERVER_ONLY-delivery-kind fold). The server-secret rows move into `server_secrets` via a boot-time config-driven reconcile (the names are per-deployment config, not migration constants; DB-row move, no provider re-provision), closing the pre-existing inject-all exposure. Managed-plane KMS is a provider-URI deployment config, not a code fork; rotation is deferred (single live key, `key_version` landed at v1, bounded key-loss blast radius — credentials are re-obtainable); per-tenant at-rest isolation + gateway-topology exposure is a tracked follow-up | Active (Matt, 2026-09-02) | [gateway-credentials at-rest encryption](server/compass-gateway-credentials-at-rest-encryption.md#d1--application-layer-aes-256-gcm-envelope-encryption) |
+| DL-326 | The DL-315 `BYPASSRLS` system-role allow-list is EXTENDED to admit the boot server-secret reconcile — a cross-tenant, request-path-free boot step that moves the configured server-secret rows from `secrets` (FORCE RLS, tenant-scoped) into `server_secrets`, run under `store.WithSystemRole`; the entrypoint enumeration is restated against the SHIPPED set, which already includes the forge-notification-ack arm (`go/internal/runnerhub/hub.go`, `forgeNotificationAck`, currently :814) that DL-315's four names omit — though `WithSystemRole`'s own doc comment already names it (tenant_tx.go:41-47), so the staleness is in DL-315's ledger prose, not the code's documentation. DL-315's load-bearing NEVER-on-the-request-path clause is unchanged — every request-path query stays fail-closed under RLS. Refines DL-315 (which stays Active) | Active (Matt, 2026-09-04) | [gateway-credentials at-rest encryption](server/compass-gateway-credentials-at-rest-encryption.md#t0--the-server_secrets-store-table-resolver-split-admin-rpc-prerequisite) |
 
 > Note (2026-07-31, RIG-1570 R5): DL-065's retired internal `ResumeContext
 > resume = 12` envelope field is NOT silently reintroduced — the collapsed