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/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= 查找。