refactor(render): drop the leading 💬 glyph from the Comments heading

Pearl was rendering the Comments subtree heading as `*** 💬 Comments [N/M]`. Craig flagged that it looks strange, and the renderer should work cleanly before it gets glyphed. I dropped the emoji prefix so the heading reads `*** Comments [N/M]`. Partly reverts 41a3396. The overlay-glyph idea (a content-aware display overlay on the leading stars) stays tracked as a separate task.

I touched pearl--format-comments (the new-subtree literal) and pearl--append-comment-to-issue (both the new-subtree insert and a couple of stale docstring references). The append-locator regex stays tolerant of the legacy `💬 Comments` heading and of the older pre-2026-05 `Comments 💬 N/N` trailing-glyph layout. Buffers rendered in any of the three states still locate their Comments heading on append.

I added one regression test (test-pearl-append-comment-locates-legacy-emoji-prefixed-heading) that seeds a `*** 💬 Comments 1/1` heading and asserts append still finds it, bumps the count to 2/2, and doesn't add a second Comments heading.

I updated assertions in test-pearl-comments.el, test-pearl-list-comments.el, and test-integration-acceptance.el to expect the no-emoji form. I also updated docstrings on pearl-fetch-comments-in-list, pearl-list-comments-count-cap, pearl--format-comments, pearl--bump-comments-count-marker, and pearl--comment-count-marker. The README's sample buffer block now matches what the renderer emits. All 669 ert tests pass. make compile and make lint are clean.

1 files changed, 15 insertions, 15 deletions

diff --git a/README.org b/README.org
index ba28157..9b3af9a 100644
--- a/README.org
+++ b/README.org
@@ -168,10 +168,10 @@ The hot-path commands sit one key under the prefix; the rest are grouped into su
 | =s= / =S=     | save the issue at point / save every issue in the file             |
 | =d=         | edit the description                                                  |
 | =m=         | open the full transient menu                                         |
-| =f= ...     | fetch: =s= pick source, =o= open issues, =p= by project, =f= filter, =v= view, =q= saved query  |
+| =f= ...     | fetch: =s= pick source, =o= open issues, =p= by project, =f= filter, =v= view, =q= saved query, =S= sync saved query to Linear, =P= publish current source  |
 | =e= ...     | edit: =d= description, =s= state, =a= assignee, =l= labels, =c= comment         |
 | =c= ...     | create: =t= issue, =c= comment                                          |
-| =k= ...     | delete: =t= issue, =c= comment                                          |
+| =k= ...     | delete: =t= issue, =c= comment, =q= saved query                          |
 | =o= ...     | open: =i= issue in browser, =v= view in Linear                           |
 | =y= ...     | copy: =u= issue URL                                                      |
 
@@ -188,18 +188,18 @@ With =which-key=, each step shows a labeled menu. Every command is also availabl
 A *source* is anything Pearl can fetch from: a Linear favorite, a Custom View, a project / cycle / label / user, a local saved query, or an ad-hoc filter. The everyday front door is =pearl-pick-source= (=C-; L f s=, or =P= in the transient), which lists all your Linear favorites first (in their Linear sort order) and then your local saved queries, each tagged by kind:
 
 #+begin_example
-  [view]              Active sprint bugs
-  [project]           Orchestration Dashboard
-  [user]              Vrezh Mikayelyan
-  [label]             security
-  [saved]             My open work
-  [saved → Eng]       Active sprint bugs (synced)
-  [saved → Personal]  My ICEBOX scratchpad (synced)
+  [view] Active sprint bugs
+  [project] Orchestration Dashboard
+  [user] Vrezh Mikayelyan
+  [label] security
+  [saved] My open work
+  [saved → Eng] Active sprint bugs (synced)
+  [saved → Personal] My ICEBOX scratchpad (synced)
 #+end_example
 
 Pick one and it fetches. List-capable favorites (Custom View / project / cycle / label / user) resolve to the existing filter or view fetch and render into the active file; non-list favorites (issue, document, dashboard, ...) open in the browser instead. Favorites are picker entries, never persisted -- a chosen favorite resolves to a concrete filter/view source before rendering, so refresh re-runs that resolved source and stays stable even if your favorites list later changes. Label and user favorites resolve by id, not by name or email, so renames in Linear don't break a saved fetch.
 
-A saved query you've synced up to Linear (see /Publishing a saved query as a Linear view/ below) renders as =[saved → <Team or Personal>] Name= so you can see at a glance which scope it lives in. The arrow reads "where it lives now." Picking it dispatches as a Linear view (server-side filter run via =customView(id:)=), not as a local filter -- any drift you've made to the view on Linear's side is honored. Plain =[saved]= entries are local-only and still run the authoring filter Pearl has on disk. =[saved → ?]= means the entry is synced but Pearl couldn't resolve the team id (deleted or renamed on Linear) -- the dispatch still works, the label is just flagging stale scope metadata.
+A saved query you've synced up to Linear (see [[*Publishing a saved query as a Linear view]] below) renders as =[saved → <Team or Personal>] Name= so you can see at a glance which scope it lives in. The arrow reads "where it lives now." Picking it dispatches as a Linear view (server-side filter run via =customView(id:)=), not as a local filter -- any drift you've made to the view on Linear's side is honored. Plain =[saved]= entries are local-only and still run the authoring filter Pearl has on disk. =[saved → ?]= means the entry is synced but Pearl couldn't resolve the team id (deleted or renamed on Linear) -- the dispatch still works, the label is just flagging stale scope metadata.
 
 If the favorites fetch fails (network/auth/transport), the picker still offers any local saved queries -- a failed fetch is not the same as "no favorites." With neither favorites nor saved queries, =pearl-pick-source= refuses with a clear message naming the missing setup.
 
@@ -209,10 +209,10 @@ A local saved query is great for your own quick filters, but the team can't see
 
 Two commands publish:
 
-| Command                            | What it does                                                       |
-|------------------------------------+--------------------------------------------------------------------|
-| =pearl-sync-saved-query-to-linear=   | Pick a saved query by name and publish (or update) it on Linear    |
-| =pearl-publish-current-source=       | Read the buffer's =#+LINEAR-SOURCE=; if it names a local saved query, publish that one |
+| Command                            | Binding                              | What it does                                                       |
+|------------------------------------+--------------------------------------+--------------------------------------------------------------------|
+| =pearl-sync-saved-query-to-linear=   | =C-; L f S=, =S= in the transient Fetch group | Pick a saved query by name and publish (or update) it on Linear    |
+| =pearl-publish-current-source=       | =C-; L f P=, =U= in the transient Fetch group | Read the buffer's =#+LINEAR-SOURCE=; if it names a local saved query, publish that one |
 
 The first time you sync a query, Pearl asks where the view should live with one enriched prompt that spells out the full end-state per option:
 
@@ -334,7 +334,7 @@ A fetched Pearl file is intentionally readable. The header records the source, r
 
   The issue description renders here as Org and can be edited in place.
 
-  *** 💬 Comments
+  *** Comments
   **** Author Name - 2026-05-23T10:00:00.000Z
   A comment, oldest first.
 #+end_src