feat(config): make one registry the authoritative declaration of every setting

[ericfitz]

Phase A of the config model redesign. Spec:
docs/superpowers/specs/2026-08-22-config-model-redesign-design.md.
Plan: docs/superpowers/plans/2026-08-22-config-registry-phase-a.md.

Why

A setting could be declared in up to four places — the Config struct's
yaml/env tags, GetMigratableSettings(), classification_registry.go, and
DefaultSystemSettings() — with nothing structural keeping them in agreement.
Two production bugs came from that drift, and the guardrail that should have
caught them structurally could not: ValidateClassifications validates whatever
slice it is handed, in practice GetMigratableSettings(), which by construction
contains only keys that already have a struct field — and which emitted
conditionally, so the validated set changed with runtime values.

What

161 settings now have exactly one declaration each, as SettingDef values in
internal/config/setting_defs_*.go. DefaultSystemSettings() and
GetMigratableSettings() became projections of it; the hand-written per-section
builders are deleted.

Guardrails, each with a demonstrated failing case:

• Total coverage — every key reachable from the Config struct or the
  classification registry has a declaration.
• Bijection — registry env vars ↔ struct env tags, compared as sets;
  every declared YAMLPath is a real yaml path.
• Transitional ratchet — a golden list of the 97 operational settings
  that still have a config/env path. It may only shrink; at zero, the cutover is
  done.
• Seeded set pinned to exactly 9 by name, and asserted against
  ClassificationFor() — the path the endpoint actually resolves through.
• Category legality — bootstrap needs both a yaml path and an env var;
  Seeded implies operational, requires a non-empty default, forbids secret,
  and forbids internal visibility.

Fixes #809

rate_limit.requests_per_minute / _per_hour were seeded into system_settings
and listed by GET /admin/settings, but 404'd on GET/DELETE because they had
no classification and unclassified resolves to VisibilityInternal.

Worth knowing before closing it: both keys are dead. Nothing reads either;
real rate limiting runs off server.disable_rate_limiting /
server.ratelimit_public_rpm. This PR classifies them, which is the
behavior-preserving fix. Deleting them or wiring them up are both behavior
changes — see the discussion on the issue.

Verification

make lint 0 · make build-server clean · make test-unit 2743 / 0 failed
· make test-integration 85 / 0 failed · oracle-db-admin APPROVED WITH
NOTES.

The Oracle review verified byte-identity empirically rather than trusting the
in-repo pins — worktree at the base commit, identical dumper test in both trees,
field-by-field diff of runtime output — confirming the 9 seeded rows and the 70
DefaultOperationalSettings() entries are unchanged. That set matters beyond
seeding: internal/dbschema/system_setting_origin_backfill.go uses it to decide
seeded-vs-explicit, which drives env-vs-database precedence on live databases.

What this found

• Five settings had no classification at all — the two rate_limit.* keys
  plus server.trusted_proxies, database.oracle_wallet_location, and
  content_token_encryption_key, the last an encryption key defaulting to
  non-secret.
• 89 of ~100 operational settings are restart-required, not hot. Mutability
  was decorative; the audit set it deliberately per entry against consuming code.
  features.saml_enabled is the traced case: NewService only builds the SAML
  manager when the boot flag is true, so the DB-backed reader gates handlers that
  a nil manager already sank.
• A latent ORA-01400. SeedDefaults' empty-value skip covers only one of its
  two loops, so a seeded setting with an empty default reaches Create(), and
  Oracle binds '' as NULL into a NOT NULL CLOB. The Seeded requires-default
  rule prevents it.
• Five guardrails could not fail and were fixed: an allowlist that
  over-exempted two keys, a test asserting over declarations instead of the
  resolution path, strings.Contains against nested YAML, a loop-guarded
  assertion with no found-flag, and a coverage leg that derives from the registry
  it checks.

Not in scope

Phases B–E: the template tool with !secret references, the per-environment
cutover, and pointing classificationFor() itself at the registry. Operational
settings still have config/env paths — that is what the ratchet measures.

Execution deviated from the plan in five recorded ways (emission stayed
conditional, chiefly); see Execution deviations at the top of the plan
document.

Follow-ups filed

#808 · #810 · #811, and a dead-setting comment on #809.

Before merge

Check AWS/RDS for a stray server.trusted_proxies row:
SELECT setting_key FROM system_settings WHERE setting_key = 'server.trusted_proxies';
Its exactClassifications entry means PUT /admin/settings/server.trusted_proxies
now 409s instead of silently writing a bootstrap-key row — an improvement, but a
deployment that exercised the old path has a row that lists yet 404s. k3s is
verified clean; RDS was not checked here because it needs credentials.

🤖 Generated with Claude Code

https://claude.ai/code/session_011gCPZA9iBjL4ugHHXuHj6t