feat(render): pin the priority range to Linear's A-D in the rendered file

Pearl maps Linear's five priorities to org cookies (A=Urgent through D=Low, no cookie = None) and tells users to set priority with org's native cookie cycling (C-c , / S-up). But that cycling obeys the user's global org-priority-lowest, which defaults to C, so on a stock Emacs you can't even cycle down to [#D]/Low, and the priority you most want to set is unreachable.

I emit a #+PRIORITIES: A D D line into every rendered file (highest A, lowest D, default D). Org reads it per-file, so the range is bounded to Linear's scale and Low is reachable regardless of the user's global setting. Verified org picks it up: org-lowest-priority becomes ?D in the rendered buffer.

This is the last piece of constraining cookies to Linear's range. The out-of-range guard (a cookie past D errors instead of silently clearing the priority) and the A-to-name legend in the help header already shipped.

1 files changed, 6 insertions, 0 deletions

diff --git a/tests/test-pearl-output.el b/tests/test-pearl-output.el
index f02df5f..55f7886 100644
--- a/tests/test-pearl-output.el
+++ b/tests/test-pearl-output.el
@@ -56,6 +56,12 @@
     (should (string-match-p "^\\* Pearl Help$" out))
     (should-not (string-match-p "^# " out))))
 
+(ert-deftest test-pearl-build-org-content-emits-priorities-range ()
+  "The header pins the priority range to Linear's A-D (highest A, lowest D) so
+cookie cycling reaches Low regardless of the user's global `org-priority-lowest'."
+  (let ((out (pearl--build-org-content '() '(:type filter :name "X" :filter nil))))
+    (should (string-match-p "^#\\+PRIORITIES: A D D$" out))))
+
 (ert-deftest test-pearl-build-org-content-source-roundtrips ()
   "The serialized source in the header reads back to the original plist."
   (let* ((source '(:type filter :name "Bugs" :filter (:labels ("bug") :open t)))