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/model-config.sh

@@ -10,6 +10,8 @@
 #   model-config.sh get {stage}      印出該階段解析後的模型鏈（逗號分隔）；未設定不印。兩種情況都 exit 0。
 #   model-config.sh list             每階段一行：stage<TAB>chain<TAB>source（project 或 global）；未設定的 chain 與 source 印「-」。
 #   model-config.sh resolve {stage}  印出該階段「目前 CLI 可用的第一個模型」單一名稱；鏈為空或無法判定時不印，exit 0。
+# 結束碼：0=查詢完成（查得到、查不到都算完成，判斷交給呼叫端）
+#         2=用法錯誤（子命令不認得，或階段不在 plan、analyze、implement、maintain 之內）
 set -u
 
 JSC_HOME="${JSC_HOME:-$HOME/.jsc}"
@@ -83,7 +85,7 @@ resolve_first_usable() { # $1=階段
 
 usage() {
   echo "用法：model-config.sh get {plan|analyze|implement|maintain} | list | resolve {plan|analyze|implement|maintain}" >&2
-  exit 1
+  exit 2
 }
 
 case "${1:-}" in