refactor(issue-body): 工作包的歸屬判準收成一個函式

wp-extract 與 wp-list 都在問「這顆工作包掛在哪顆需求底下」。規則寫兩份，
某天只會有一邊被改到，而分岔的樣子是「清單裡看得到、抽取卻說不是」。
順手把測試裡兩種取段落的寫法統一，並刪掉沒有人傳過的參數。

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

scripts/wp-list.js

@@ -6,9 +6,9 @@
  * 單位是工作包。這一支把「哪幾顆工作包掛在這顆需求底下」答出來，讓他從清單裡挑一顆，
  * 而不是自己去 Gitea 網頁上翻。
  *
- * **判準沿用工作包抽取那一套**：關聯段落裡的 `需求議題：#<編號>`（見 wp-extract 的
- * `需求議題` 欄位，解析同樣走 issue-body 的 referencedIndex）。不另發明判準——標籤、
- * 標題前綴、相依關係都各有各的用途，拿它們當歸屬會與抽取契約分岔。
+ * **判準沿用工作包抽取那一套**：關聯段落裡的 `需求議題：#<編號>`。判準與 wp-extract 的
+ * `需求議題` 欄位共用 issue-body 的 requirementIndex，不是各寫一份長得像的解析——
+ * 標籤、標題前綴、相依關係都當得了歸屬判準，但各發明一套就會與抽取契約分岔。
  *
  * **PR 不算工作包。** 每個 PR 都是議題，而 pr-create 產出的 PR 描述本來就有
  * 「需求議題：#N」那一行，只看 body 會把 PR 混進清單裡。
@@ -28,7 +28,7 @@ import {
   preflight,
   resolveLogin,
 } from './lib.js';
-import { parseSections, referencedIndex } from './issue-body.js';
+import { parseSections, requirementIndex } from './issue-body.js';
 
 main(async () => {
   const flags = parseFlags(process.argv.slice(2), {
@@ -83,5 +83,5 @@ main(async () => {
  */
 function belongsTo(issue, requirement) {
   if (issue.pull_request != null) return false;
-  return referencedIndex(parseSections(issue.body), '關聯', '需求議題') === requirement;
+  return requirementIndex(parseSections(issue.body)) === requirement;
 }