fix(cli): 分開「模型不合格」與「腳本被叫錯」的結束碼

model-tags.sh 的 gate 原本用同一個結束碼表示兩件事：模型缺能力標籤，
以及這支腳本被叫錯。delegate 讀到用法錯誤時，會當成模型沒通過檢查，
默默把一個能用的模型丟掉。真正的錯在哪，永遠不會浮出來。現在用法錯誤
改走另一個碼，兩種「無法判定」也歸到同一個碼，呼叫端只要認碼就分得出
三種結果。model-config.sh 照同一套規則調整，兩支腳本的契約才一致。

check-requires.sh 在沒有 python3 的機器上，會直接讓 shell 回一個沒宣告過
的碼，呼叫端讀不到原因。現在先確認 python3 在不在，並印出擋下的理由，
manifest 相依檢查才是真的做得到的事。

delegate 的七個步驟原本沒有任何完成條件，引用了不存在的 plugin，也把
CLI 偵測與標籤篩選寫成文字敘述，可是這兩件事早就有腳本負責。挑模型那
一步需要模型 id，全篇卻沒有任何步驟產得出來。現在每一步都寫出完成條件，
資料一律取自腳本，模型夠不夠格由結束碼判定，不讓模型自評標籤。

setup 的環境變數重驗原本去讀目前這個 shell。可是寫進 rc 檔的值，要等新的
shell 起來才存在，所以重驗永遠回報「沒設到」，把修好的項目誤判成失敗。
現在只驗 rc 段落裡確實有那一行，環境層面交給下一次體檢。

tools/check-requires.sh

@@ -1,5 +1,14 @@
 #!/usr/bin/env sh
-# check-requires.sh — Check jsc.requires before updating one plugin.
+# check-requires.sh — 更新單一 plugin 之前，檢查它宣告的 jsc.requires 最低版本。
+# 用法：
+#   check-requires.sh {claude|codex|copilot|antigravity|kiro} {manifest}
+# 輸出（單行，可供程式判讀）：
+#   status=ok reason={沒有宣告相依版本|相依版本符合：...}
+#   status=blocked reason={缺哪一個 plugin、差哪一版，或 manifest 讀不到}
+# 結束碼：0=通過（沒有宣告相依，或全部符合）
+#         1=擋下（相依版本不符、缺相依 plugin、manifest 不存在或不是有效 JSON、缺 python3）
+#         2=用法錯誤（參數個數不對，或 CLI 代號不在五個之內）
+# deploy.sh update 在每個 domain 更新前呼叫一次；擋下就跳過該 domain，不更新到一半才失敗。
 set -u
 
 usage() {
@@ -21,6 +30,12 @@ esac
   exit 1
 }
 
+command -v python3 >/dev/null 2>&1 || {
+  # 直接讓 shell 回 127 的話，呼叫端會看到一個沒宣告過的結束碼，也讀不到原因。
+  printf 'status=blocked reason=找不到 python3，無法解析 manifest：%s\n' "$MANIFEST"
+  exit 1
+}
+
 JSC_HOME_DIR="${JSC_HOME:-$HOME/.jsc}"
 LOCAL_DIR="${JSC_LOCAL_PLUGINS:-$JSC_HOME_DIR/plugins}"
 KIRO_SKILLS="${JSC_KIRO_SKILLS:-$HOME/.kiro/skills}"