D36：修正四個零件契約的假資訊敘述（現行沒有發 API key 的機制）

leo 07-29 指正：「現在沒有 partner key，改用 namespace，現在沒有發 API key 的機制」。
這些契約寫著 'KBDB partner key（ak_xxx）'／'租戶識別（ak_ 前綴）'＝假資訊源——
總管就是被它騙的（先把範例改成不存在的 {{credential.kbdb_partner_key}}），
不修的話下一個 AI 會再挖同一個坑。

改：kbdb_upsert_block／auth_oauth2／auth_service_account／auth_static_key 的
api_key description，改述為「租戶識別＝Arcrun namespace」＋註明 examples 裡的
ak_test/ak_nonexistent 是測試假值不代表真實格式。

只動 description，不動 schema／欄位名／gherkin_tests
（api_key 欄位名保留——改名會破壞現有 workflow）。
驗：四檔 YAML 可解析、required 不變、欄位清單不變、gherkin_tests 全保留、
ak_test 等測試值原封不動。

人閘：leo 07-29 跑 scripts/component-arm.sh 解保險授權。

registry/components/auth_static_key/component.contract.yaml

@@ -24,7 +24,11 @@ input_schema:
       description: 目前僅支援 authenticate;static_key 無 refresh 概念
     api_key:
       type: string
-      description: 租戶識別(ak_ 前綴),用來組 {api_key}:cred:{name} KV key
+      description: >-
+        租戶識別＝Arcrun namespace，用來組 {api_key}:cred:{name} KV key。
+        ⚠️ 2026-07-29 更正：舊敘述寫「ak_ 前綴」，但現行沒有發 API key 的機制
+        （leo 07-29 指正）——namespace 即身分即憑證。下方 examples 的 ak_test/ak_nonexistent
+        是測試用假值，不代表真實格式。
     service:
       type: string
       description: auth recipe 名稱,對應 auth_recipe:{service} 的 KV 記錄