feat(time-log): 對既有議題重跑時補到當下，每一輪各記一筆

原本的終點一律是議題的建立時間，所以對既有議題重跑時相減為負，補登直接 no-op——
那一輪的規劃時間就這樣掉了，而那正是這顆議題要修的毛病，只是換個位置出現。

終點改成看議題是不是這一輪建立的：是就補到議題建立那一刻（第一次跑），不是就補到
補登的當下（重跑）。回報多出 `迄` 與 `依據` 兩個欄位，讓人一眼看出這一筆補的是哪一段。

「這顆議題上已經有工時就跳過」這條規則拿掉了，它與累計互斥。防重複只剩一條：錶已經
跑在這顆議題上——那一段已經有錶在記，補下去會與錶涵蓋的區間重疊。連帶把 lib 的
listIssueTimes 一起移除，沒有人再用它。

實跑驗過（議題 #57）：補登 121 秒、起錶、停錶 7 秒，兩筆都進得了週報，驗完刪除。
議題 #57 的規格同步更正，另外兩處過期的敘述也一併改掉。

議題 #57

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

prompts/sdlc-plan.md

@@ -102,8 +102,9 @@ node scripts/issue-create.js --repo <owner/name> --title "<標題>" --body-file
 node scripts/time-log.js --repo <owner/name> --index <編號> --since <記下的開始時間> --dry-run
 ```
 
-長度由腳本自己算——它讀議題的建立時間減掉 `--since`，所以不必自己做減法，也不會讓
-兩邊的時鐘各算一次。確認無誤後拿掉 `--dry-run` 再跑一次。
+長度由腳本自己算，不必自己做減法，也不會讓兩邊的時鐘各算一次。終點看議題是不是這一輪
+建立的：是就補到**議題建立那一刻**，不是（對既有議題重跑）就補到**現在**——那一輪的
+規劃時間照樣要進報表。確認無誤後拿掉 `--dry-run` 再跑一次。
 
 **不設時間上限，照實補登。** 中途去開會的那兩個小時會一起被算進去，這是刻意的：換來
 這個流程不必為此多長一題出來問使用者。時間記多了看得出來，記不到就永遠找不回來。
@@ -114,8 +115,11 @@ node scripts/time-log.js --repo <owner/name> --index <編號> --since <記下的
 node scripts/timer.js --repo <owner/name> --index <編號> --dry-run
 ```
 
-一樣先試跑，確認無誤後拿掉 `--dry-run` 再跑一次。順序反過來的話補登會被當成「這一步做過了」而跳過——錶在這顆議題上跑著，正是
-`time-log` 判斷補過了的依據之一，它也因此重跑不會愈補愈多。
+一樣先試跑，確認無誤後拿掉 `--dry-run` 再跑一次。
+
+順序不能反過來：錶一旦跑在這顆議題上，`time-log` 就會跳過不補——那一段已經有錶在記了，
+再補一次會與錶涵蓋的區間重疊。**重跑是累計不是覆蓋**，每一輪各記一筆，報表上加總起來
+才是這顆議題真正花掉的規劃時間。
 
 錶已經跑在別顆議題上時起錶會被擋下（`STOPWATCH_ON_OTHER_ISSUE`）。**照實告訴使用者
 是哪一顆，請他自己去停**，不要代勞：那一段時間該記在哪顆議題上只有他知道。順帶說明