Opt-in purpose value allowlists for direct consultation routes

[jeremi]

Migrated from: jeremi/registry-relay#132
Original author: @jeremi
Source repository: jeremi/registry-relay
Source issue: #132
Source labels: post-1.0
Source milestone/release intent: none
Target area/path: crates/registry-relay

Issue

[redacted private/internal deployment detail during migration]

Relay purpose semantics are presence-plus-audit by frozen decision (D5, 2026-06-11): the Data-Purpose value is recorded verbatim, never validated (verified: presence check only at src/api/entity.rs:670-680). That is right when Notary is the purpose-certification layer; it is weak for direct Relay consultation deployments.

Fix direction: optional, opt-in purpose value allowlists (entity, aggregate, and standards-surface scopes) for deployments that need direct Relay purpose checks. Default behavior unchanged (presence-only); denied values are rejected with a stable error code and the denial is audited. No change to the frozen Data-Purpose wire semantics — this is server-side policy on the existing header.

Acceptance: allowlist rejects a denied purpose and audits the denial; default config behavior unchanged; docs state clearly that this is not legal-basis validation.

Note: one or more private/internal references were redacted during migration.

Migration Metadata

• Migrated to the public monorepo on 2026-06-25.
• Source title, body, labels, milestone/release intent, and pre-migration discussion were preserved where available.
• Code-grounded audit note: Opt-in purpose allowlists for direct consultation routes remain open.
• Private/internal references, secrets, and obvious deployment-only details were redacted instead of copied forward.