Add case true of pattern for long condition chains

Follow-up from PR review: nested if is the right answer for two or three
dependent conditions, but past that the nesting becomes the problem. AL's
case statement is the flat alternative — the control statements
documentation states a value set "must be an expression or a range" and
that the first matching value set executes, so case true of / case false of
accept boolean expressions and stop at the first match. That is the
laziness the boolean operators do not provide.

Adds case-true-of-for-long-condition-chains.md with good/bad AL companions:
case false of for guard chains where every condition must hold, case true of
for first-match dispatch. The bad sample shows both failure shapes — a
five-level if ladder, and the worse escape of collapsing it into an and
chain, which trades nesting for a real defect.

Cross-links both articles, and adds the threshold to the short-circuit
article's Best Practice so following it does not lead to a deep ladder.

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

community/knowledge/performance/case-true-of-for-long-condition-chains.bad.al

@@ -0,0 +1,28 @@
+codeunit 50543 "Perf Sample CaseChain Bad"
+{
+    procedure IsShippableLine(SalesLine: Record "Sales Line"): Boolean
+    var
+        Item: Record Item;
+    begin
+        // Five levels of nesting to sequence five guards. The evaluation order is
+        // carried by indentation alone and the body drifts steadily right.
+        if SalesLine.Type = SalesLine.Type::Item then
+            if SalesLine."No." <> '' then
+                if SalesLine."Qty. to Ship" > 0 then
+                    if Item.Get(SalesLine."No.") then
+                        if not Item.Blocked then
+                            exit(true);
+        exit(false);
+    end;
+
+    procedure IsShippableLineCollapsed(SalesLine: Record "Sales Line"): Boolean
+    var
+        Item: Record Item;
+    begin
+        // The wrong escape from the ladder: flattening it into 'and' trades the
+        // nesting for a defect, because every operand is still evaluated. Item
+        // fields are read even when the Get failed.
+        exit((SalesLine.Type = SalesLine.Type::Item) and (SalesLine."No." <> '') and
+             (SalesLine."Qty. to Ship" > 0) and Item.Get(SalesLine."No.") and (not Item.Blocked));
+    end;
+}