Add retention policy knowledge to the privacy domain (#177)

* 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

* Address review feedback on retention policy knowledge

- Scope both articles to bc-version [17..] (retention policies shipped in v17).
- Allowed-tables sample: add OnRefreshAllowedTables subscriber with a
  ForceUpdate path; the upgrade tag now gates one-time setup only.
- Default-policy sample: use Retention Policy Setup.FindOrCreateRetentionPeriod
  instead of a hand-rolled lookup-then-insert that can collide on code.
- Anti-pattern now keys on append-only tables rather than table names.
- al-privacy-review: add retention-policy tokens and deterministic routing
  for both articles, with a bounded per-table text search for delete and
  registration paths.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* Address second review round on retention policy knowledge

- Scope both articles to bc-version [22..]: FindOrCreateRetentionPeriod
  first appears in the 21.1 System Application and OnRefreshAllowedTables
  in 22.
- Reframe the default-setup article as optional guidance; registration
  without a setup is valid. The anti-pattern and review routing now cover
  only false claims that registration alone cleans up data.
- Make all four samples self-contained: declare Contoso Activity Log in
  each, add the Retention Policy Setup permission, and guard the default
  setup on IsAllowedTable.
- Let evaluation overrides list additionalArticles and register both
  retention pairs as extra privacy cases (38 cases, existing IDs unchanged).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* Revert evaluation harness change for multiple articles per domain

The harness intentionally evaluates one paired article per domain. Keep it
as designed; how the retention pairs join privacy evaluation is left to the
maintainers.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* Register retention policy pairs in the privacy evaluation override

Use main's articles override so both retention article pairs get positive
and clean cases alongside no-pii-in-telemetry-message-string.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

---------

Co-authored-by: Jeremy Vyska <jeremy@sparebrained.com>
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

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

@@ -0,0 +1,87 @@
+table 50566 "Contoso Activity Log"
+{
+    DataClassification = SystemMetadata;
+
+    fields
+    {
+        field(1; "Entry No."; Integer) { AutoIncrement = true; }
+        field(2; "Activity"; Text[250]) { }
+    }
+
+    keys
+    {
+        key(PK; "Entry No.") { Clustered = true; }
+    }
+}
+
+codeunit 50560 "Contoso Reten. Pol. Setup"
+{
+    Access = Internal;
+
+    procedure AddAllowedTables()
+    begin
+        AddAllowedTables(false);
+    end;
+
+    // ForceUpdate re-registers even after the upgrade tag is set, so the
+    // table comes back when an administrator refreshes the allowed tables.
+    procedure AddAllowedTables(ForceUpdate: Boolean)
+    var
+        ContosoActivityLog: Record "Contoso Activity Log";
+        RetenPolAllowedTables: Codeunit "Reten. Pol. Allowed Tables";
+        UpgradeTag: Codeunit "Upgrade Tag";
+        IsInitialSetup: Boolean;
+    begin
+        IsInitialSetup := not UpgradeTag.HasUpgradeTag(AllowedTableTag());
+        if not (IsInitialSetup or ForceUpdate) then
+            exit;
+
+        if not RetenPolAllowedTables.IsAllowedTable(Database::"Contoso Activity Log") then
+            RetenPolAllowedTables.AddAllowedTable(
+                Database::"Contoso Activity Log",
+                ContosoActivityLog.FieldNo(SystemCreatedAt),
+                28); // support cases need at least four weeks of log history
+
+        if IsInitialSetup then
+            UpgradeTag.SetUpgradeTag(AllowedTableTag());
+    end;
+
+    local procedure AllowedTableTag(): Code[250]
+    begin
+        exit('Contoso-ActivityLogAllowedTable-20260910');
+    end;
+
+    [EventSubscriber(ObjectType::Codeunit, Codeunit::"Reten. Pol. Allowed Tables", OnRefreshAllowedTables, '', false, false)]
+    local procedure AddAllowedTablesOnRefreshAllowedTables()
+    begin
+        AddAllowedTables(true);
+    end;
+}
+
+codeunit 50561 "Contoso Reten. Pol. Install"
+{
+    Subtype = Install;
+    Access = Internal;
+
+    trigger OnInstallAppPerCompany()
+    var
+        ContosoRetenPolSetup: Codeunit "Contoso Reten. Pol. Setup";
+    begin
+        ContosoRetenPolSetup.AddAllowedTables();
+    end;
+}
+
+codeunit 50562 "Contoso Reten. Pol. Upgrade"
+{
+    Subtype = Upgrade;
+    Access = Internal;
+
+    // Install code does not run on upgrade, so tenants that already have the
+    // app get their registration here.
+    trigger OnUpgradePerCompany()
+    var
+        ContosoRetenPolSetup: Codeunit "Contoso Reten. Pol. Setup";
+    begin
+        ContosoRetenPolSetup.AddAllowedTables();
+    end;
+}