Add new action skills for AL testing and documentation

- Introduced `al-test-writer` to generate AL test codeunits for production objects based on TDD principles.
- Added `al-userguide-test-writer` to create test codeunits from user guide steps, mapping actions and assertions.
- Implemented `bc-extension-test-guide` to generate a comprehensive TEST_GUIDE.md for Business Central extensions, covering various categories.
- Created `bc-webclient-runner` to automate UI testing of the Business Central web client, capturing screenshots and asserting UI states.
- Developed `page-scripting-e2e` to produce a recording plan for Page Scripting, ensuring a structured approach to browser-level testing.

custom/knowledge/integration/park-long-running-work-on-a-status-url.bad.al

@@ -0,0 +1,32 @@
+// Anti-pattern: a Job Queue tight loop that Sleep-polls the status URL, with the retry count in
+// a local variable that resets on restart. The loop pins a Job Queue slot for the entire
+// external wait, and the counter never survives long enough to drive real backoff or give-up.
+
+codeunit 50202 "Long Running Bad"
+{
+    procedure Start(var IntegrationMessage: Record "Integration Message")
+    var
+        Client: HttpClient;
+        Response: HttpResponseMessage;
+        Location: array[1] of Text;
+        RetryCount: Integer; // BAD: lost on restart; this state belongs on the message row
+    begin
+        Client.Post('https://svc.contoso.com/api/jobs', BuildContent(IntegrationMessage), Response);
+        Response.Headers().GetValues('Location', Location);
+
+        // BAD: a tight Sleep-poll loop INSIDE the Job Queue handler. This single flow now holds a
+        // Job Queue worker slot for the whole external wait. A flow that can take hours starves
+        // every other job behind it, because the slot is occupied doing nothing but sleeping.
+        repeat
+            Sleep(5000);
+            // BAD: RetryCount is a local. Every BC restart resets it to zero, so backoff and the
+            // give-up threshold below never behave correctly across a restart: the loop effectively
+            // starts over, having forgotten how long it has already been waiting.
+            RetryCount += 1;
+            Client.Get(Location[1], Response);
+        until IsComplete(Response) or (RetryCount > 1000);
+
+        // The flow lives only in this session. If BC recycles the session mid-wait, the work is
+        // orphaned: nothing parked it, so nothing will ever resume it.
+    end;
+}