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>

test/sdlc-feat-assets.test.js

@@ -133,6 +133,19 @@ test('邊界把第一段不做的事分開列，且明講不寫本機狀態檔',
   assert.match(boundary, /換一台機器或換一個 agent/, '要說明為什麼不留狀態檔');
 });
 
+test('第三段收尾時告訴使用者之後怎麼查 PR，但不自己反覆跑', () => {
+  assert.match(phase3, /pr-watch\.js/);
+  assert.match(phase3, /worktree-remove\.js/, '手動清理的出口也要講，否則沒人知道它在');
+  assert.match(phase3, /不要自己反覆跑/);
+  assert.match(phase3, /suggestedAction/, '建議動作是列舉值，要讓使用者知道有這個東西可以判斷');
+});
+
+test('邊界擋住「監看報了就自己去跑 sdlc-fix」', () => {
+  const boundary = prompt.slice(prompt.indexOf('## 邊界'));
+  assert.match(boundary, /不自動反覆執行 `pr-watch`/);
+  assert.match(boundary, /只由使用者明確叫用/);
+});
+
 // ── 第二段：逐項實作 ───────────────────────────────────────────────
 
 test('第二段明講改的是工作樹裡的檔案，不是主工作區', () => {