Add 18 more community AL/BC patterns across appsource, data-modeling, error-handling, security, style, testing, ui, upgrade, and web-services

Second contribution from CURABIS ApS, generalized from patterns observed across real AppSource/PTE development. Cross-checked against the current microsoft/knowledge corpus before opening; several originally-drafted candidates were dropped as duplicates of existing files.

microsoft/knowledge/data-modeling/code-must-not-change-workdate.md

@@ -0,0 +1,40 @@
+---
+bc-version: [all]
+domain: data-modeling
+keywords: [workdate, session-setting, user-control, side-effect]
+technologies: [al]
+countries: [w1]
+application-area: [all]
+---
+
+# Application code must not change the WorkDate
+
+## Description
+
+The work date is a per-user session setting the user controls from the
+client (the date shown in the top-right corner, used to default posting
+dates and date filters). Application code must never call the `WorkDate`
+function to set a new value. Doing so changes what the user sees and
+defaults to for the rest of their session, as a side effect of running
+unrelated business logic — a surprising, hard-to-trace behavior change the
+user never asked for and has no visibility into.
+
+This is a call-direction distinction: reading the current work date via
+`WorkDate` (or `WorkDate()` with no argument) is fine and common — it is
+only the assignment form, `WorkDate(NewDate)`, that is the anti-pattern.
+
+## Best Practice
+
+Read the work date to default a value; never write to it.
+
+See sample: `code-must-not-change-workdate.good.al`.
+
+## Anti Pattern
+
+Setting the work date from within a codeunit, report, or page action
+changes session state the user owns, for the duration of a call that has
+nothing to do with the user's date preference. If a scenario genuinely
+needs a specific date for a calculation, pass or compute that date as a
+local variable — never repurpose the session's `WorkDate`.
+
+See sample: `code-must-not-change-workdate.bad.al`.