Add retention policy knowledge to the privacy domain

Two articles covering retention policies for extension-owned tables,
the gap that lets high-volume log tables grow unbounded:

- register-owned-log-tables-for-retention-policies: an extension's own
  log tables must be added to the allowed-tables list from install AND
  upgrade code, guarded by IsAllowedTable plus an upgrade tag, with a
  mandatory minimum retention where audit needs one.
- ship-a-default-retention-policy-setup: registration only makes a table
  selectable; nothing is deleted until a Retention Policy Setup record
  exists, so ship one (disabled by default) as the platform's own
  Retention Policy Installer does.

Each ships good/bad AL samples. Claims verified against the BC admin
docs and the Retention Policy module in microsoft/BCApps.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011gvTjm746MtJEVWeRTbG46

microsoft/knowledge/privacy/register-owned-log-tables-for-retention-policies.bad.al

@@ -0,0 +1,17 @@
+codeunit 50563 "Contoso Activity Log Cleanup"
+{
+    Access = Internal;
+
+    // The log table is never added to the allowed tables, so it cannot appear
+    // on the Retention Policies page. Cleanup is hard-coded here instead:
+    // the period is not configurable, the deletion is not written to the
+    // Retention Policy Log, and an administrator cannot switch it off.
+    trigger OnRun()
+    var
+        ContosoActivityLog: Record "Contoso Activity Log";
+    begin
+        ContosoActivityLog.SetFilter(
+            SystemCreatedAt, '<%1', CreateDateTime(CalcDate('<-30D>', Today()), 0T));
+        ContosoActivityLog.DeleteAll();
+    end;
+}