refactor(lib): 停錶與議題工時清單下沉到 lib

停錶原本只長在 pr-create 裡，而規劃與分析接下來也要停自己的錶（議題 #57）。
那段容錯邏輯——「錶沒在跑」的狀態碼隨站台版本而異，認的是狀態碼在 409/500
這一組**且**訊息說的是碼錶——各寫一份遲早會在某一邊漏掉一種狀態碼，而它漏掉的
症狀正是「事情做完了卻回報失敗」。

順手把簽章改成與同伴一致的 (login, repo, index)：fetchIssue、listIssueTimes、
stopwatchOnIssue 都這樣收，只有它收一條手組的路徑字串。

新增 listIssueTimes 供補登判斷「這顆議題上已經有工時了嗎」。它在議題讀得到卻
404 時報 TIME_TRACKER_OFF，與四層前置檢查第四層說同一句話——試跑不跑前置檢查，
那句話得由它自己說，否則試跑看到的是一句看不懂的 404。

議題 #57

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

scripts/pr-create.js

@@ -36,6 +36,7 @@ import {
   preflight,
   readTextFile,
   resolveLogin,
+  stopStopwatch,
 } from './lib.js';
 
 /** 描述的固定段落，順序即 reviewer 閱讀的順序 */
@@ -126,7 +127,7 @@ main(async () => {
   );
 
   // 錶只在 PR 確實存在之後才停。既有的 PR 也要停——那一步可能正是上次中斷的地方。
-  const stopped = await stopStopwatch(login, stopPath);
+  const stopped = await stopStopwatch(login, issueRepo, index);
 
   return {
     repo,
@@ -211,28 +212,3 @@ function checkTestResult(body) {
     );
   }
 }
-
-/**
- * 「這顆議題上沒有碼錶在跑」的回法不只一種：看過 500，也看過 409。
- * 狀態碼隨站台版本而異，所以認的是「狀態碼在這一組裡 **且** 訊息說的是碼錶」——
- * 只看訊息會把真的伺服器錯誤一起吞掉，只看狀態碼會把別的衝突也當成沒錶。
- */
-const NO_STOPWATCH_STATUS = [409, 500];
-
-/**
- * 停錶。錶沒在跑時不算失敗——PR 已經開出去了，把整件事報成失敗只會讓人以為
- * PR 沒開成而重跑一次。
- */
-async function stopStopwatch(login, path) {
-  const response = await giteaRequest(login, 'POST', path, { body: {} });
-  if (response.status >= 200 && response.status < 300) return true;
-
-  if (
-    NO_STOPWATCH_STATUS.includes(response.status) &&
-    /stopwatch/i.test(response.body?.message ?? '')
-  ) {
-    return false;
-  }
-  expectOk(response, `POST ${path}`);
-  return false;
-}