Feature: Privacy policy compiler for pipeline-safe media handling

## Summary
Add a privacy policy compiler that converts tenant data-handling rules into enforceable pipeline, media, search, and export constraints.

## Problem / Opportunity
The project has redaction operators, retention policies, GDPR documentation, and refusal of raw sinks, but privacy behavior is spread across multiple services. Tenants need a single policy surface that can express constraints such as required face/plate redaction, maximum retention, export restrictions, searchable fields, and allowed model classes, then have the platform enforce those constraints consistently.

## Proposed Feature
Introduce a tenant-scoped privacy policy language and compiler. The compiler should validate proposed pipelines, media operations, semantic-search indexing, evidence exports, and agent/tool actions against the active policy, producing actionable problem details and audit records when work is refused.

## Scope
- Define a versioned privacy policy resource with validation and examples.
- Compile policies into checks used by pipeline-service, media-service, semantic-search, compliance-evidence-service, and policy-gate-service.
- Add explainable refusal output for developers and operators.
- Add console editing/review with diff and dry-run against existing resources.
- Add docs mapping policy fields to GDPR/DPIA controls.
- Add test fixtures for common privacy profiles.

## Acceptance Criteria
- [ ] A tenant can create, validate, activate, and roll back privacy policy revisions.
- [ ] Pipeline compilation refuses DAGs that violate required redaction or prohibited model-class rules.
- [ ] Media export and retention operations are checked against the active policy.
- [ ] Semantic-search indexing refuses fields disallowed by policy.
- [ ] Policy refusals are audited and returned as RFC 9457 problem details with remediation hints.
- [ ] Documentation includes at least three realistic tenant policy examples.

## Non-Goals
- Replacing legal review or external compliance assessment.
- Creating a general-purpose policy engine for all authorization decisions.
- Weakening existing bounded-autonomy gates.

## Dependencies / Risks
- Cross-service enforcement can drift unless checks share a common package or generated policy artifact.
- Policy changes may need migration/dry-run tooling to avoid breaking existing pipelines unexpectedly.
- The language must be expressive enough without becoming unreviewable.

## Open Questions
- Should this build on OPA/Rego or a smaller project-native policy schema?
- Which policy changes should require approval gates by default?