Migrate Policy retention interfaces

docs/INTERFACE_PATTERN_MIGRATION.md

@@ -0,0 +1,19 @@
+# Policy Interface Pattern Migration
+
+Policy contributes four retention-administration sections to the Access-owned
+administration host. It does not own an independent route or shell.
+
+| Surface | Archetype | Consequence and provenance | Evidence |
+| --- | --- | --- | --- |
+| System retention | Effective-policy editor plus destructive operation | Typed values show their effective source path. Applying retention can irreversibly redact or delete eligible content and therefore requires explicit confirmation; dry-run and applied outcomes are distinguished. | `RetentionPoliciesPanel.tsx`, Core `RetentionPolicyScopeManager`, interface-pattern structural test |
+| Tenant retention | Effective-policy editor | A tenant may only narrow fields that system policy allows. Read-only authority and parent locks are explicit. | Core policy-source and blocker components |
+| Group retention | Targeted effective-policy editor | Group selection is loaded through bounded delta requests; missing target, parent lock, and write authority remain distinct states. | Target loader plus Core retention editor |
+| User retention | Targeted effective-policy editor | User labels expose only authorized account metadata; retained data itself is never returned by this administration surface. | Target loader plus Core retention editor |
+
+The retention execution result is a typed, filterable outcome table. Raw JSON
+is neither the primary policy editor nor the operator result view. The backend
+remains authoritative for policy validation, narrowing rules, destructive
+effects, redaction, and audit evidence.
+
+Contextual help uses `policy.retention` and `privacy.retention`, which resolve
+through the optional Docs module or the hosted documentation fallback.