merge(pr-留言): 把議題支援套到 pr-threads 的共用結構上

#48 把留言讀取抽成 pr-threads 給 pr-watch 與 pr-comments 共用，本分支則在修「純議題讀不了」
與「已處理的判定有兩份」。兩邊動到同一塊，但要的其實是同一件事——#48 的檔頭就寫著
「規則寫兩份遲早會各自演化，一邊認自己打的 +1、另一邊認任何人的」，而那正是本分支在
lib 與 pr-comments 之間發現的那個 bug。

合併的方向是保留 pr-threads 的結構，把修正套進去：

- readGeneral 改名 readGeneralComments 並導出，pr-comments 判斷出是純議題時只叫它。
  先讀 /issues/{index} 再決定要不要翻 review——每個 PR 都是議題，反過來不成立。
- pr-threads 自己那份 markedByMe 拿掉，改用 lib 的 mergedByMe。抽取契約數未整併則數
  用的是同一條規則，現在三處共用一份，#48 擔心的分歧不會再發生。
- pr-comments 的試跑改印 commonRequests：它收得下兩種輸入，而試跑階段還沒讀過議題、
  不知道是哪一種。與其假設是 PR 而列出五個（對純議題有三個根本不會發），不如只列一定
  會發的，其餘交給 note。pr-watch 的輸入一定是 PR，繼續用 plannedRequests。

lib.js 與 sdlc-feat.md 兩邊改的是不同區域，三方合併無衝突。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

prompts/sdlc-feat.md

@@ -309,6 +309,27 @@ repo**（錶停在那裡）。兩者常常不是同一個——議題在需求
 - 碼錶是否已停；沒停的話把腳本回的那句說明一起帶出來
 - 議題上還有沒有沒勾完的待辦（理論上應該沒有；有的話要說出來）
 
+### 17. 告訴使用者之後怎麼查
+
+PR 開出去之後就交給 reviewer 了。**把下面這件事講給使用者聽，不要自己反覆跑**：
+
+```
+node scripts/pr-watch.js --repo <owner/name> --index <PR 編號>
+```
+
+問一次答一次：PR 狀態、還有幾則留言沒處理、工作樹在哪、裡面有沒有沒提交的東西，
+以及固定列舉值的 `suggestedAction`（`run-sdlc-fix`／`cleanup`／`nothing-to-do`／
+`blocked-dirty`）。多久跑一次由使用者自己排（cron 或他自己的循環機制），
+本工具不長出排程器。
+
+PR 合併或關閉時它會順手清掉那棵工作樹，**本機分支與遠端分支都留著**；工作樹裡還有
+沒提交的東西就會擋下來（`blocked-dirty`），由使用者自己處理。永遠不會被合併也不會被
+關閉的那些 PR，用手動出口清：
+
+```
+node scripts/worktree-remove.js --repo <owner/name> --branch <分支名>
+```
+
 ## 邊界
 
 - 第一段**不改任何一行程式碼**、不勾待辦、不提交、不開 PR——那些是後面幾段的事。
@@ -324,6 +345,8 @@ repo**（錶停在那裡）。兩者常常不是同一個——議題在需求
 - 不把實作規範或註解格式寫進目標專案的任何檔案。
 - 不改與待辦無關的程式碼；順手想修的東西記下來說出來，不要摸進這次的變更裡。
 - 不為了勾選在議題上留留言。
+- **不自動反覆執行 `pr-watch`**，也不因為它建議了 `run-sdlc-fix` 就自己去跑 `/sdlc-fix`——
+  流程只由使用者明確叫用。
 - 不自行建立標籤。缺「進行中」標籤時中止並請使用者建立。
 - 不代替使用者停錶，也不在被鎖擋下時繞過去。
 - 不替使用者決定來源分支。