feat: add exact retention help contexts

docs/CONTEXTUAL_HELP_CONTRACT.md

@@ -46,6 +46,8 @@ than adding custom `F1` listeners:
 - `interfaceId` identifies a durable UI surface or action.
 - `helpContextId` identifies a documentation context when it differs from the
   interface identity.
+- `helpModuleId` identifies the documentation-owning module when a shared
+  control is embedded in another module's page.
 - `helpTopicId` links directly to a module-owned documentation topic.
 - translated label keys provide deterministic field identities for ordinary
   `FormField`, `ToggleSwitch`, search, date/time, email, button, dialog, and card

docs/LOCALIZATION_AND_HELP_QUALITY.md

@@ -32,6 +32,16 @@ should still add exact `metadata.help_contexts` entries for consequential,
 unfamiliar, policy-controlled, destructive, security-sensitive, or legally
 meaningful fields and actions.
 
+The shared retention-policy editor exposes explicit contexts for each stored
+data category, audit-detail control, lower-level override switch, target
+selector, reload, and save action. The Policy module owns the matching German
+administrator guidance. Retention execution surfaces use separate contexts for
+dry-run, destructive apply, confirmation, and outcome review so F1 opens the
+consequence and recovery guidance closest to the focused control.
+Shared controls may set `helpModuleId` when their documentation owner differs
+from the containing page; the retention editor uses this to resolve Policy help
+from both administration and Campaign surfaces.
+
 The generated `help_review_candidates` list is therefore a content-depth queue,
 not a list of controls on which F1 cannot work. It should prioritize: