docs(heicode): set Azure Key Vault as secret-store baseline

Align Manager docs with code-enforced azkv:// secret_ref baseline.

Reviewed: docs-only, no code/runtime impact. Follow-up required in heicodeDocs to remove OpenBao/vault:// drift.

docs/heicode.md

@@ -142,13 +142,13 @@ P1 permission manifest 示例：
 
 SaaS 场景下，凭证不能转嫁给用户手工管理。用户负责授权，平台负责托管、隔离、轮换、撤销和审计。
 
-优先方案：
+**密钥保管库基线 = Azure Key Vault（`azkv://`）。** 已裁决：统一使用 Azure Key Vault，不使用 OpenBao / HashiCorp Vault；`secret_ref` 一律 `azkv://<vault>/secrets/<name>`，代码强制该前缀（`controller/resource.go`、`agent_approval.go`、`secret_store.go`），不向后兼容 `vault://`。
 
 | 方案 | 判断 |
 |------|------|
-| HashiCorp Vault | 优先选择。Kubernetes Auth、Policy、TTL、动态密钥、审计能力成熟，适合 AKS 中的子 Agent 运行时授权 |
-| Infisical | 可选方案。产品体验较好，但需要验证 SaaS 多用户隔离策略和运行时授权能力 |
-| Azure Key Vault | 适合 Azure 优先部署，也可以作为 Secret Provider 的一种实现 |
+| **Azure Key Vault** | **采用**。当前 Secret Store 基线；通过 REST + 用户分配托管身份（Managed Identity）访问，`secret_ref` 前缀 `azkv://` |
+| HashiCorp Vault / OpenBao | 不采用（历史候选，已弃；代码中无此路径） |
+| Infisical | 不采用 |
 
 Secret Broker 负责：
 
@@ -172,7 +172,7 @@ Agent 平台底层是 AKS，因此运行时权限应和 Kubernetes 身份绑定
 -> Manager 记录 Resource Grant
 -> Manager 请求 Agent 平台部署
 -> Agent 平台为 deployment / role 创建 K8s ServiceAccount
--> Agent 平台绑定 Vault policy 或 Workload Identity
+-> Agent 平台绑定 Azure Workload Identity / Managed Identity
 -> 子 Agent Pod 运行时只能访问被授权的 secret
 ```