feat(assistant): 存取庫掃描接上 {repo} 代入點

新增 tools/scan-repos.sh：掃出工作目錄底下的存取庫，交出 {repo} 要代的
那份清單，順便對出每一個存取庫的 REPO_{HASH} 盤點頁頁名（雜湊規則與
盤點頁那一支相同，實測值一致）。

掃描起點刻意沒有預設值。給一個預設就等於猜，而猜錯的後果不是掃不到，
是在猜錯的那些目錄底下跑指令——往上一層是家目錄、再往上是整台機器，
而那一輪沒有人看得到它跑到哪裡去了。沒設就回 3 並說要設哪一個變數。
深度預設一層、上限三層；點開頭的目錄、符號連結、路徑帶空白或殼層特殊
字元的三種一律不交出去，但逐個印出來——那是真的存在卻沒被盤點到的
存取庫，只印一個總數會讀成整批都掃過了。

run-due.sh 改成兩個代入點都代：{cli} 取偵測到的 CLI 代號、{repo} 取
掃到的存取庫，兩個都帶的那一筆目標數是乘積。待辦簿那一筆的 repo 欄
有值時只代那一個，值可以是路徑也可以是 {owner}/{repo}；對不出來就
印 held=，不退回全部存取庫——那一筆指名了一個目標。代入之後再驗一次
禁止字元，因為代進去的值是這一輪現場算出來的。

schedule.sh 把 JSC_ASSIST_SCAN_ROOT 與 JSC_ASSIST_SCAN_EXCLUDE 快照進
排程條目。少了掃描起點，帶 {repo} 的內建項每一輪都代不出目標，而那一輪
只印一行 held=，看起來像這一批還沒接上、不像一個變數沒進條目。

同時補兩個只有真的執行才發現得了的缺陷：

一、cron 一行的長度上限只在寫入那一刻由 crontab 自己擋，--dry-run 那一路
根本不碰它，所以預演每一次都過。實測踩過一次：整條 PATH 快照進條目那一批
預演全綠、安裝回結束碼 4。改成建好條目就量，兩個模式都印 entry_len= 與
上限，達到上限當場拒絕並指出長度是從哪幾個快照變數來的。

二、run-due.sh 截錯誤訊息用的 cut -c 數的是位元組不是字元，中文字剛好被
截在中間就在報告上留下一個替代字元。改成截完再過一次 iconv -c 丟掉那個
不完整的序列。這一種不會有人來報：亂碼不影響結束碼。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

tools/schedule.sh

@@ -125,6 +125,9 @@
 #   JSC_WIKI_REPO_{TYPE}       各頁型的 wiki 存取庫。已設定的全部快照進條目。名單是當下從
 #                              環境撈出來的，不寫死，所以新增頁型自動涵蓋，這支不必跟著改。
 #                              目錄頁那一支專用變數也在裡面
+#   JSC_ASSIST_SCAN_ROOT       存取庫掃描的起點。install 當下快照進條目；沒有它，帶 {repo}
+#                              代入點的內建項每一輪都代不出目標
+#   JSC_ASSIST_SCAN_EXCLUDE    存取庫掃描的排除清單。install 當下快照進條目
 set -u
 
 MARK_PREFIX='# jsc-assist:assistant'
@@ -133,6 +136,7 @@ STATE_DIR="$JSC_HOME/assistant"
 CURRENT="$JSC_HOME/current"
 LOG="$STATE_DIR/schedule.log"
 CRONTAB_CMD="${JSC_ASSIST_CRONTAB_CMD:-crontab}"
+CRON_LINE_MAX="${JSC_ASSIST_CRON_LINE_MAX:-1000}"
 TASK_PREFIX='jsc-assist-assistant'
 
 DRYRUN=0
@@ -344,7 +348,12 @@ snapshot_names() {
   # 巡檢那一輪要跑的指令本身走的是字面絕對路徑、不靠 PATH；靠 PATH 的是那幾支腳本自己
   # 呼叫的外部程式，所以修在條目這一層，不是逐支腳本各自去猜安裝路徑——猜就要維護一份
   # 路徑清單，而清單會過期。
-  printf '%s\n' GITEA_HOST GITEA_TOKEN JSC_HOME JSC_ASSISTANT_HEARTBEAT_TTL
+  # 掃描起點與排除清單也要快照。存取庫掃描那一支刻意不猜掃描起點，沒有值就整個代入點
+  # 代不出來，帶 {repo} 的內建項每一輪都會被跳過——而那一輪只會印一行 held=，看起來像
+  # 「這一批還沒接上」，不像「有一個變數沒進條目」。排除清單少了同樣要命：殼裡排除掉的
+  # 那幾個目錄，在排程那一輪會被當成要盤點的存取庫。
+  printf '%s\n' GITEA_HOST GITEA_TOKEN JSC_HOME JSC_ASSISTANT_HEARTBEAT_TTL \
+    JSC_ASSIST_SCAN_ROOT JSC_ASSIST_SCAN_EXCLUDE
   env 2>/dev/null \
     | sed -n 's/^\(JSC_WIKI_REPO\)=.*/\1/p; s/^\(JSC_WIKI_REPO_[A-Za-z0-9_]*\)=.*/\1/p' \
     | sort -u
@@ -708,6 +717,25 @@ crontab_install() {
     printf '\n' >>"$_new"
   done
 
+  # 條目長度先量過再往下走，兩個模式都量。
+  #
+  # cron 的一行有長度上限，超過就整批寫不進去，而錯誤訊息是 crontab 自己吐的一句
+  # 「command too long」。實測踩過：把整條 PATH 快照進條目之後 install 回 4——而同一組參數的
+  # --dry-run 全綠，因為那一路根本不碰 crontab。一道只在真的寫入時才會發現的限制，等於
+  # 沒有預檢。
+  # 上限取 1000：那是 vixie-cron 的 MAX_COMMAND，不是這台機器上量出來的，所以留一個變數
+  # 可以覆寫。這台機器實測 810 字元的條目裝得進去，加上整條 PATH 的那一次裝不進去。
+  for _job in $JOBS; do
+    _len=$(cron_entry "$_job" | wc -c | tr -d ' ')
+    printf 'entry_len=%s job=%s limit=%s\n' "$_len" "$_job" "$CRON_LINE_MAX"
+    if [ "$_len" -ge "$CRON_LINE_MAX" ]; then
+      die 4 "$_job 的條目有 $_len 個位元組，達到 cron 一行的上限 $CRON_LINE_MAX，這一批裝不進去。條目長度的來源是環境變數快照（$SNAPSHOT_NAMES）與 PATH 快照——先看哪一個值特別長，多半是掃描起點或排除清單寫得太長。縮短那個值，或用 JSC_ASSIST_CRON_LINE_MAX 覆寫上限（覆寫之前先確認這台機器的 cron 真的收得下）。"
+    fi
+    if [ "$_len" -ge $((CRON_LINE_MAX - 100)) ]; then
+      warn "$_job 的條目有 $_len 個位元組，距離 cron 一行的上限 $CRON_LINE_MAX 不到 100。再多加一個環境變數快照就會裝不進去，而那一次的錯誤訊息只會說 command too long。"
+    fi
+  done
+
   if [ "$DRYRUN" -eq 1 ]; then
     for _job in $JOBS; do
       printf 'dryrun=crontab job=%s entry=%s\n' "$_job" "$(cron_entry "$_job" | mask_secret)"