Finish safe site settings and SEO exceptions; park redirects (umbrella)

Parent epic: #7

Split children: #187 (site navigation), #188 (sponsors). Accepted and closed slice: #114 (safe site-settings registry, announcement group, Studio + admin-API adapters, tests, deployment evidence).

Original intake title: "Manage navigation, announcements, sponsors, redirects, and safe site settings". This umbrella now tracks only what remains after the accepted #114 slice and the two groomed children.

What already has an owner

Normative specs

• 01 — Data ownership: database-owned operational settings, redirect manifest and exceptional URL rules, navigation overrides, announcements, sponsors; secrets never database-backed.
• 02 — URL, link, SEO compatibility: every intentional URL/canonical/metadata change is parity work or an explicit reviewed exception; redirect/retirement records require owner, reason, and test; no catch-all homepage redirect.
• 06 — Studio and admin API: Site section scope; management parity contract; one capability registry; roles; audit model.
• 07 — Security, privacy, operations: secrets stay in the secret store; management surfaces private/no-store; redaction.
• Open decision #18 / issue #29: preservation-first production cutover scope and its exception-approval mechanism.
• #114's accepted contract is the binding precedent for every new settings group: code-owned registry definition, shared query/batch services, capability/role synchronization, Studio + admin-v1 adapters, generated OpenAPI and bidirectional parity checks, uncached public resolution, redacted audit.

Scope

1. Remaining safe site-settings groups

Extend the existing core.configuration.OperationalSettingDefinition registry and core/site_settings.py services group by group, exactly as #114 did for site.announcement. Each new group:

• defines code-owned, immutable, startup-checked definitions (key, group, label, description, type, default, validation, docs reference, lifecycle, cache policy, sensitivity);
• is registered only when a concrete product need names the setting — no speculative settings;
• reuses the one shared query service and one shared batch command service with CAS revisions, actor-scoped idempotency, append-only revisions, and one redacted audit event per changed batch;
• extends Studio /studio/settings and GET/POST /api/v1/admin/settings rather than adding new routes, with regenerated OpenAPI and passing make check-management-parity;
• maps read/write onto the existing core.read_operational_settings / core.change_operational_settings permissions and the existing role matrix unless a group genuinely needs narrower authority, which requires its own grooming note in the delivering issue;
• keeps only public-safe or safe-indicator values in the database and never secret/bootstrap configuration.

2. SEO exception records (pending #29's mechanism)

The database-owned "exceptional URL rules" from specification 01 are the explicit approved exceptions that #29's acceptance criteria require for the preservation-first cutover: each intentional deviation from exact URL/content/SEO parity needs one reviewed record with exact target, kind (canonical, noindex, metadata, alias), owner, reason, approval evidence, review date, and a test.

This umbrella owns that record family, but its exact workflow (who approves, what evidence is stored, what review cadence applies, and how it maps to the cutover report under #77) must not be invented before the owner accepts #29's preservation-first scope and exception-approval mechanism, or records a replacement. Until #29 resolves, no SEO-exception implementation proceeds; when it resolves, this umbrella's SEO-exception scope is groomed into its own child issue following the #114/#187/#188 pattern before any code.

3. Redirect and retirement records (parked)

Explicit redirect/410 manifest records remain parked behind open decision #29. Specification 02 already fixes their shape in outline — exact source/destination/status, owner, reason, test, loop/chain/homepage-catch-all rejection, one-hop behavior, raw-query preservation — and the current site serves code-owned canonical/alias behavior from the checked route manifests with no database redirect store. Nothing in this umbrella may create a database redirect/retirement record, retire a URL, or change redirect cache classes while #29 is open.

Non-goals

• No reimplementation of anything #114 shipped, no navigation work (owned by #187), and no sponsor work (owned by #188).
• No arbitrary site-settings CRUD, database-authored definitions, environment/Django-setting editor, feature-flag platform, or settings requiring database availability before bootstrap.
• No secret, credential, token, provider, webhook, private-URL, or signing-key value in the registry, database, UI, API, or audit trail.
• No unreviewed redirect, no catch-all homepage redirect, and no redirect analytics while #29 is open.
• No GitHub editorial override: GitHub-owned fields are never silently replaced by database values, and no Studio authoring-to-GitHub workflow is implied here (open decision #12 governs that separately).
• No HTML/script/Markdown injection surface in any value, and no public personalization.

Dependencies

• #114 (closed) is the prerequisite and precedent; #31, #86, #87 (closed) supply the shared primitives; open #107 supplies the development owner/token surface for any new capability's principal reconciliation.
• #29 is a hard gate for the redirect pillar and for finalizing the SEO-exception workflow; #77's release acceptance report is the consumer of SEO-exception records.
• Open #32/#33 and decisions #20/#28 remain production identity/high-risk follow-ups, not implementation blockers, as accepted for #114.
• Open #109 owns any future anonymous-cache classification/invalidation for pages that render database-owned settings values.

Acceptance criteria

• Each newly registered settings group ships as code-owned definitions with schema, validation, ownership, default/source badge, lifecycle, and cache behavior, startup-checked, and is exposed through the existing Studio settings page and admin settings endpoints with regenerated OpenAPI and passing parity checks.
• Each new group reuses the #114 shared services for validation, all-or-none CAS, actor-scoped idempotency, revisions, and redacted audit, with Studio/API parity and role/field permissions proven by tests.
• Security-critical bootstrap and secret values remain environment/Secrets-Manager-only and are provably absent from the registry, adapters, API responses, and audit trail.
• SEO-exception records (once #29 records the owner's mechanism) require exact target, kind, owner, reason, approval evidence, review date, and a passing test, and reject undefined or catch-all targets.
• Redirect/410 work stays parked while #29 is open; no database redirect record, URL retirement, or redirect cache-class change lands under this umbrella before that decision.
• Cross-process visibility, fail-closed public behavior, and negative/security tests for every new group follow the #114 evidence bar.

Test scenarios

1. Per new settings group: definition registry checks, default/override resolution, type/length/control/markup validation, unknown or partial batches, stale CAS, idempotent replay, audit redaction, and next-request public visibility across processes.
2. SEO exceptions (after #29): approved and unapproved deviations, missing owner/reason/test, expired review, and their appearance in the cutover report's exception list.
3. Parked-redirect guard: any redirect-shaped change attempted under this umbrella fails review; existing code-owned alias/canonical behavior is unchanged.

Browser scenarios

Per delivered settings group, at 1440x900 and 390x844: manage and verify the group in /studio/settings, observe the public effect on the next request, and cover empty, error, stale, and denied states with screenshots under .tmp/screenshots/. SEO-exception and redirect browser work is not applicable while those pillars are parked.

Start by reading accepted issue #114 and the referenced specifications, then check open decision #29. No implementation is ready while the SEO and redirect work is gated and no concrete settings group is named. Done requires a groomed child issue for a specific settings group or the approved mechanism for the deferred records.