chore(gitea): 技能依結束碼分流，可併行的步驟改成同時跑

技能以前只寫成功路徑。腳本回非 0 時，模型得自己猜下一步，猜錯就是靜靜
往下走。現在每一支腳本在檔頭宣告自己的結束碼，技能也逐碼寫明要停、要
問、還是要改參數再呼叫一次。兩支技能補上連線變數的解析步驟，讓缺值在
第一步就浮出來，而不是在中途撞出一行英文錯誤。

流程也拉平了。取內容、選範本、問輸出位置這幾件事彼此不相依，改成同一批
送出；存取庫批次同步從逐一處理改成各存取庫同時進行，一個 owner 底下有
上百個存取庫時差距最明顯。

相依的技能組下限寫進外掛設定，版本推進。

tools/pr-watch.sh

@@ -12,8 +12,14 @@
 #       照樣印出來再退出，退出碼仍是 0：留言不會因為 PR 剛好合併就消失。
 # 輸出: 全部繁中，留言行維持 gitea.sh pr-comments 的原格式
 #       「{時間}<TAB>{作者}<TAB>{類型}<TAB>{內容}」，呼叫端可直接用 cut -f 取欄位。
-# 退出碼: 0 = PR 已合併或關閉，印出最終狀態；10 = 有新留言待呼叫端跑決策樹；
-#         2 = 參數錯誤或第一輪就連不上 Gitea；3 = 查不到該 PR。
+# 結束碼: 0=PR 已合併或關閉，最終狀態印在 stdout。盯完了，不用再盯一次。
+#         2=用法或環境問題：參數個數不對、第一個參數不是 {owner}/{repo}、PR 編號不是數字、
+#           JSC_PR_WATCH_INTERVAL 不是正整數秒、建不出暫存檔，或第一輪就連不上 Gitea。
+#           照 stderr 的訊息修參數或 GITEA_HOST、GITEA_TOKEN，再重新盯。
+#         3=查不到該 PR。確認存取庫與 PR 編號再重新盯，不要原樣重試——
+#           編號打錯會變成永遠輪詢一支不存在的 PR。
+#         10=有新留言，內容印在 stdout。接手跑決策樹處理完，再重新盯同一支 PR。
+#         130=收到 INT 或 TERM 訊號而中止。狀態檔留著，重新盯會從上次那則留言接下去。
 # 護欄: gitea.sh pr-status 對不存在的 PR 會印「? none none」並且 exit 0。
 #       所以 state 只認 open 與 closed、merged 只認 true 與 false，對不上就回 3。
 #       少了這道白名單，PR 編號打錯會變成永遠輪詢一支不存在的 PR。