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, 5 insertions, 0 deletions

diff --git a/pearl.el b/pearl.el
index d2423ae..caa60e9 100644
--- a/pearl.el
+++ b/pearl.el
@@ -4006,6 +4006,11 @@ no side effects."
       ;; so the buffer always opens unfolded down to the issue headings.
       (insert (format "#+STARTUP: show%dlevels\n" (if groups 3 2)))
       (insert (format "#+TODO: %s\n" (pearl--derive-todo-line states)))
+      ;; Pin the priority range to Linear's five-point scale (A=Urgent .. D=Low;
+      ;; no cookie = None).  Bounds org cookie cycling (C-c , / S-up) to A-D
+      ;; per-file, so Low (D) is reachable even when the user's global
+      ;; `org-priority-lowest' stops at C.  Highest A, lowest D, default D.
+      (insert "#+PRIORITIES: A D D\n")
       ;; Source-tracking metadata: the serialized source drives refresh; the
       ;; rest is human-readable provenance.
       (when account