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

Start by reading the tracked issue #590 and dependency #592, then inspect the existing Registry Stack profile and control concepts described there. Use the golden classified Manifest, pinned safeguard profile, and registryctl report or explain entry point as the integration targets. Done means deterministic per-field controls, stable diagnostics and explanations, bounded redacted output, and clearly non-enforcing report behavior.

Written by the indexing model from the issue text.