Fix four merge-critical issues from Jesper's 2026-09-22 review

- al-testing-review.md: the generic ExpectedError cue's asserterror
  Assert.IsTrue/IsFalse exclusion was unconditional, but the
  specialized rule it deferred to only claims the pure-inversion
  shape. A test expecting the guarded Boolean-returning call itself to
  raise fell through both routes. Narrowed the exclusion to the same
  inversion-only condition the specialized cue already uses.
- asserterror-needs-expectederror-and-code.md: the rollback-sentinel
  exception (a trailing asserterror Error(...) used purely to force a
  fixture rollback, not to verify a specific failure) previously lived
  only in skill routing prose. Encoded it directly in the article's
  Anti Pattern section so every consumer of the knowledge base sees it,
  not just this one skill.
- commit-shared-test-fixture-inside-lazy-initialize.good.al/.bad.al:
  replaced hand-rolled Item.Init()/Insert(true) with
  LibraryInventory.CreateItem, so the canonical fixture doesn't itself
  trigger use-library-codeunits-for-test-fixtures.
- table-relation-test-exclude-known-invalid-relations-via-event.good.al/
  .bad.al: declared minimal "Sample Setup"/"Sample Header" tables
  inline instead of referencing undefined symbols, matching this
  repo's own convention that every fixture is self-contained.

microsoft/knowledge/testing/asserterror-needs-expectederror-and-code.md

@@ -23,4 +23,6 @@ See sample: [`asserterror-needs-expectederror-and-code.good.al`](asserterror-nee
 
 `asserterror DoInvalid();` with nothing after it. The test asserts only that the call failed somehow; swap the validation for a different bug and the test still passes, certifying a guard that may no longer fire. A negative test that cannot tell one error from another verifies almost nothing.
 
+Not an instance of this anti-pattern: a trailing `asserterror Error(SomeLabel)` used purely as an end-of-test rollback sentinel to undo a lazily-initialized shared fixture's scratch changes (see `commit-shared-test-fixture-inside-lazy-initialize.md`). That `Error` call exists to force a rollback, not to verify that a specific failure occurred — the sentinel's own text is not meant to be asserted against, and adding an `ExpectedError` there would just duplicate the label without checking anything the test doesn't already control.
+
 See sample: [`asserterror-needs-expectederror-and-code.bad.al`](asserterror-needs-expectederror-and-code.bad.al).

microsoft/knowledge/testing/commit-shared-test-fixture-inside-lazy-initialize.bad.al

@@ -3,6 +3,7 @@ codeunit 50142 "Sample Test Library"
     Subtype = Test;
 
     var
+        LibraryInventory: Codeunit "Library - Inventory";
         Initialized: Boolean;
         SharedItemNo: Code[20];
         RollBackMsg: Label 'Revert back the tables to their original state.';
@@ -22,9 +23,7 @@ codeunit 50142 "Sample Test Library"
     var
         Item: Record Item;
     begin
-        Item.Init();
-        Item."No." := 'SAMPLE-SHARED';
-        Item.Insert(true);
+        LibraryInventory.CreateItem(Item);
         SharedItemNo := Item."No.";
     end;
 

microsoft/knowledge/testing/commit-shared-test-fixture-inside-lazy-initialize.good.al

@@ -3,6 +3,7 @@ codeunit 50142 "Sample Test Library"
     Subtype = Test;
 
     var
+        LibraryInventory: Codeunit "Library - Inventory";
         Initialized: Boolean;
         SharedItemNo: Code[20];
         RollBackMsg: Label 'Revert back the tables to their original state.';
@@ -21,9 +22,7 @@ codeunit 50142 "Sample Test Library"
     var
         Item: Record Item;
     begin
-        Item.Init();
-        Item."No." := 'SAMPLE-SHARED';
-        Item.Insert(true);
+        LibraryInventory.CreateItem(Item);
         SharedItemNo := Item."No.";
     end;
 

microsoft/knowledge/testing/table-relation-test-exclude-known-invalid-relations-via-event.bad.al

@@ -1,3 +1,29 @@
+table 50144 "Sample Setup"
+{
+    fields
+    {
+        field(1; "Primary Key"; Code[10]) { }
+        field(2; "Default Category Code"; Code[20]) { }
+    }
+    keys
+    {
+        key(PK; "Primary Key") { Clustered = true; }
+    }
+}
+
+table 50145 "Sample Header"
+{
+    fields
+    {
+        field(1; "No."; Code[20]) { }
+        field(10; "Category Code"; Code[20]) { }
+    }
+    keys
+    {
+        key(PK; "No.") { Clustered = true; }
+    }
+}
+
 codeunit 50141 "Sample Table Relation Test Ext"
 {
     [EventSubscriber(ObjectType::Codeunit, Codeunit::"Table Relation Test", 'OnAfterRemoveTableRelation', '', false, false)]

microsoft/knowledge/testing/table-relation-test-exclude-known-invalid-relations-via-event.good.al

@@ -1,3 +1,32 @@
+table 50144 "Sample Setup"
+{
+    fields
+    {
+        field(1; "Primary Key"; Code[10]) { }
+        field(2; "Default Category Code"; Code[20]) { }
+    }
+    keys
+    {
+        key(PK; "Primary Key") { Clustered = true; }
+    }
+}
+
+table 50145 "Sample Header"
+{
+    fields
+    {
+        field(1; "No."; Code[20]) { }
+        // A known exception: this field is allowed to reference "Sample
+        // Setup" loosely (no TableRelation enforced here on purpose), so
+        // the standard Table Relation Test would otherwise reject it.
+        field(10; "Category Code"; Code[20]) { }
+    }
+    keys
+    {
+        key(PK; "No.") { Clustered = true; }
+    }
+}
+
 codeunit 50141 "Sample Table Relation Test Ext"
 {
     [EventSubscriber(ObjectType::Codeunit, Codeunit::"Table Relation Test", 'OnAfterRemoveTableRelation', '', false, false)]