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/ship-a-default-retention-policy-setup.bad.al

@@ -0,0 +1,18 @@
+codeunit 50565 "Contoso Reten. Pol. Register"
+{
+    Subtype = Install;
+    Access = Internal;
+
+    // The table becomes selectable on the Retention Policies page and nothing
+    // else happens: no Retention Policy Setup record is created, so no period
+    // is proposed and no data is ever deleted. The log table keeps growing
+    // until someone notices the tenant's storage consumption.
+    trigger OnInstallAppPerCompany()
+    var
+        ContosoActivityLog: Record "Contoso Activity Log";
+        RetenPolAllowedTables: Codeunit "Reten. Pol. Allowed Tables";
+    begin
+        RetenPolAllowedTables.AddAllowedTable(
+            Database::"Contoso Activity Log", ContosoActivityLog.FieldNo(SystemCreatedAt));
+    end;
+}