Define safeguard profiles and compile an explainable per-field control plan

Tracked by #590. Depends on #592.

## Outcome

A deployment can select a versioned, digest-pinned safeguard profile and deterministically compile reviewed field classifications into an explainable per-field minimum-control plan. This issue is report and explanation only; it does not change request-time enforcement.

## Requirements

- Define a versioned safeguard-profile artifact with identity, version, review state, digest, supported classification terms, rule identifiers, and minimum-control requirements.
- Keep the safeguard profile separate from semantic profiles and descriptive Manifest ODRL.
- Model controls at the level Registry Stack can reason about, including exposure projection, purpose/PDP requirements, filter restrictions, relationship expansion, aggregation, attribute release, audit handling, and redaction requirements.
- Classify each outcome as `enforceable`, `declared_external`, or `unsupported` for the selected Registry Stack version and feature set.
- Compile classifications, selected profiles, existing explicit Relay controls, and feature availability into one deterministic per-field plan.
- Preserve monotonicity: derived requirements and explicit configuration may add restrictions, but no derived rule may remove an existing restriction.
- Reject ambiguous precedence, unknown policy-driving terms, conflicting rules, unsupported required controls, and digest mismatches.
- Produce stable rule IDs, a canonical policy hash, and value-free explanation output suitable for review and audit.
- Add `registryctl` report or explain output without exposing source field values, secrets, environment contents, or credentials.
- Keep report mode visibly non-enforcing and prevent it from being presented as compliance evidence.

## Acceptance criteria

- [ ] A golden classified Manifest and pinned safeguard profile compile into deterministic per-field controls.
- [ ] Explanation output identifies every classification, profile rule, explicit control, effective requirement, and enforcement status.
- [ ] Most-restrictive-wins behavior is tested independently of rule order and display names.
- [ ] Unknown, ambiguous, conflicting, and unsupported required rules fail with stable field-addressed diagnostics.
- [ ] The compiler cannot turn an existing purpose, scope, filter, redaction, or audit requirement off.
- [ ] Explanation output is bounded and redaction-tested.
- [ ] Report-only deployments cannot claim that the control plan is enforced.

## Non-goals

- Request-time PDP changes
- Route-specific enforcement
- A legal compliance verdict
- Runtime fetching of safeguard profiles
- Treating a framework principle as a field-classification namespace

Inizia leggendo l’issue tracciata #590 e la dipendenza #592, quindi esamina il profilo Registry Stack esistente e i concetti di controllo descritti al suo interno. Usa il Manifest classificato golden, il profilo di safeguard fissato e il punto di ingresso report o explain di registryctl come obiettivi di integrazione. Il lavoro è completato quando sono presenti controlli deterministici per campo, diagnostica e spiegazioni stabili, un output limitato e redatto e un comportamento di report chiaramente non applicativo.

Scritto dal modello di indicizzazione a partire dal testo della issue.