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

- api-page-key-fields-must-be-editable-on-insert.good.al and
  stored-derived-fields-must-not-be-exposed-directly.good.al: both were
  writable API pages missing DelayedInsert = true, contradicting this
  repo's own api-page-delayedinsert-true rule - the canonical "good"
  samples were teaching code BCQuality itself flags.
- dimension-management-wiring.good.al: UpdateDimensionSetID exited
  early when Customer.Get failed, leaving the previous customer's
  shortcut dimension and Dimension Set ID in place - the same staleness
  bug the InheritFromDimSetID = 0 fix (from the prior review round) was
  meant to prevent, just triggered by a failed lookup instead of a
  successful one. Now clears the shortcut field and recomputes with an
  empty source list on a failed lookup too, so GetDefaultDimID
  correctly returns an empty Dimension Set ID instead of never running.

microsoft/knowledge/data-modeling/dimension-management-wiring.good.al

@@ -71,15 +71,17 @@ table 50101 "Course Registration Header"
         DefaultDimSource: List of [Dictionary of [Integer, Code[20]]];
         GlobalDim2Code: Code[20];
     begin
-        if not Customer.Get("Customer No.") then
-            exit;
-
-        // Recompute from scratch (InheritFromDimSetID = 0): passing the existing
-        // "Dimension Set ID" here would inherit dimensions from whichever record
-        // the document was previously linked to, retaining them even after the
-        // new customer's defaults have nothing for that dimension.
+        // Recompute from scratch (InheritFromDimSetID = 0) whether or not the
+        // customer lookup succeeds. Passing the existing "Dimension Set ID"
+        // here would inherit dimensions from whichever record the document
+        // was previously linked to, and exiting early on a failed Get would
+        // leave that same stale data in place — both defeat the point of
+        // this procedure. Clearing the shortcut field and recomputing with
+        // an empty source list (when the customer doesn't exist) correctly
+        // clears the document's dimensions instead of leaving old ones.
         "Shortcut Dimension 1 Code" := '';
-        DimMgt.AddDimSource(DefaultDimSource, Database::Customer, "Customer No.");
+        if Customer.Get("Customer No.") then
+            DimMgt.AddDimSource(DefaultDimSource, Database::Customer, "Customer No.");
         "Dimension Set ID" :=
             DimMgt.GetDefaultDimID(
                 DefaultDimSource, '', "Shortcut Dimension 1 Code", GlobalDim2Code, 0, 0);

microsoft/knowledge/data-modeling/dimension-management-wiring.md

@@ -24,7 +24,7 @@ Skipping the model that actually matches the table's kind produces a field that
 
 For a master table, validate each shortcut dimension field through `ValidateDimValueCode`, save the result with `SaveDefaultDim`, and delete the matching Default Dimension records in `OnDelete`.
 
-For a document table, when the field that attaches the document to a master record changes (e.g. `Customer No.`), call `AddDimSource` naming that master table and key, then `GetDefaultDimID` to compute the document's new `Dimension Set ID`, inheriting the master's Default Dimension records. Pass `0` for `GetDefaultDimID`'s `InheritFromDimSetID` argument in this case — passing the document's *existing* `Dimension Set ID` instead inherits whatever dimensions were already in it, so a value the previous linked record supplied can survive into the new one even where the new record has no default for that dimension. Validate the document's own Shortcut Dimension fields through `ValidateShortcutDimValues`, which updates that same `Dimension Set ID` in place rather than persisting a separate Default Dimension record.
+For a document table, when the field that attaches the document to a master record changes (e.g. `Customer No.`), call `AddDimSource` naming that master table and key, then `GetDefaultDimID` to compute the document's new `Dimension Set ID`, inheriting the master's Default Dimension records. Pass `0` for `GetDefaultDimID`'s `InheritFromDimSetID` argument in this case — passing the document's *existing* `Dimension Set ID` instead inherits whatever dimensions were already in it, so a value the previous linked record supplied can survive into the new one even where the new record has no default for that dimension. Run this same recompute — clear the shortcut field, call `GetDefaultDimID` with no source added — when the lookup on the new key fails (blank or an invalid value), too: exiting early instead leaves the previous record's dimensions in place, which is the same staleness bug the `InheritFromDimSetID = 0` rule exists to prevent. Validate the document's own Shortcut Dimension fields through `ValidateShortcutDimValues`, which updates that same `Dimension Set ID` in place rather than persisting a separate Default Dimension record.
 
 See sample: [`dimension-management-wiring.good.al`](dimension-management-wiring.good.al).
 

microsoft/knowledge/web-services/api-page-key-fields-must-be-editable-on-insert.good.al

@@ -9,6 +9,7 @@ page 50101 "Customer Info API"
     SourceTable = Customer;
     ODataKeyFields = "No.";
     InsertAllowed = true;
+    DelayedInsert = true;
 
     layout
     {

microsoft/knowledge/web-services/stored-derived-fields-must-not-be-exposed-directly.good.al

@@ -7,6 +7,7 @@ page 50102 "Project Task API"
     EntityName = 'projectTask';
     EntitySetName = 'projectTasks';
     SourceTable = "Project Task";
+    DelayedInsert = true;
 
     layout
     {