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_oauth2/component.contract.yaml

@@ -27,7 +27,11 @@ input_schema:
         refresh — 強制重新 refresh，更新 CREDENTIALS_KV 中的 access_token/expires_at
     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 記錄

registry/components/auth_service_account/component.contract.yaml

@@ -24,7 +24,11 @@ input_schema:
       description: 目前僅支援 authenticate
     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 記錄

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 記錄

registry/components/kbdb_upsert_block/component.contract.yaml

@@ -20,7 +20,12 @@ input_schema:
   properties:
     api_key:
       type: string
-      description: KBDB partner key（ak_xxx）
+      description: >-
+        租戶識別＝Arcrun namespace（送出時放 X-Arcrun-API-Key header）。
+        ⚠️ 2026-07-29 更正：舊敘述寫「KBDB partner key（ak_xxx）」，但**現行沒有發
+        API key 的機制**（leo 07-29 指正）——namespace 即身分即憑證。
+        workflow 裡一律寫 {{credential.arcrun_namespace}}，值由執行期解析（D36）。
+        欄位名維持 api_key（改名會破壞現有 workflow），只是它裝的是 namespace。
     page_name:
       type: string
       description: 當 idempotency key。內部用 GET /blocks?page_name= 查找。