Clarify subscription probe key semantics

docs/EXECUTION_BOARD.md

@@ -195,6 +195,11 @@
   - 已补充重复导入自动复用策略：按 `provider_id + api_key_fingerprint + canonical_model_family` 判断 `reused / patch_only / replace`
   - 已补充同模型别名归一化契约：例如 `kimi 2.6 / kimi-2.6 / kimi-k2.6` 可归并到同一模型家族并快速复用
   - 已补充多账号重复导入与弃用账号再启用策略：active 账号提示“重复已启用”，disabled/deprecated 账号显示原状态并走 `reactivated` 快速启用路径
+  - 已修正 access closure artifact 的 probe key 语义漂移：`subscription` 现在持久化 `requested_probe_api_key`、`effective_probe_key_source`、`effective_probe_key_fingerprint`，不再把外部 raw key 伪装成 `probe_api_key`；`probe_api_key` 仅继续用于 `self_service` 向后兼容
+  - 最新干净本地 fresh-host 验收 `artifacts/real-host-acceptance/20260523_local_clean_minimax_subscription_probe_semantics` 已验证：
+    - `subscription` closure 会正确区分 `requested_probe_api_key` 与 `managed_subscription` 实际 probe 来源
+    - 同一轮 raw key 直打宿主仍返回 `403 not assigned to any group`
+    - provider completion 仍受 MiniMax 官方 upstream `429 rate_limit_error` 影响，但这已不再会被 artifact 误读成 raw key 可用
 
 **本轮实现状态（T1 ~ T13）**：
 - [x] `internal/batch` canonical types / reuse policy / service / confirmation / validation / projection 已落地

docs/REAL_HOST_ACCEPTANCE_LEARNINGS.md

@@ -31,6 +31,17 @@
    - closure 最终用于宿主 `/v1/models` 探测的，不是外部传入的原始 `access_api_key`
    - 真正使用的是 CRM 在宿主侧创建/查找出来的 managed key（`sk-relay-*` 风格）
    - 因此 subscription 验收如果直接拿调用方原始 probe key 去打 `/v1/models`，出现 `403 not assigned to any group` 并不代表 CRM 主链路失败，而是 probe key 用错了
+   - latest-head 当前实现已把 artifact 语义拆开：
+     - `requested_probe_api_key` 记录调用方传入原始 key
+     - `effective_probe_key_source=managed_subscription` 记录实际 gateway probe 来源
+     - `effective_probe_key_fingerprint` 记录实际 probe key 指纹
+     - `probe_api_key` 只继续保留给 `self_service`，不再在 `subscription` closure 里复用
+   - 2026-05-23 的干净本地 fresh-host 验收 `artifacts/real-host-acceptance/20260523_local_clean_minimax_subscription_probe_semantics` 已再次证明这层语义修复生效：
+     - closure 里 `requested_probe_api_key=sk-raw-probe-20260523b`
+     - `effective_probe_key_source=managed_subscription`
+     - 不再出现 legacy `probe_api_key`
+     - 同一轮 raw key 直打宿主 `/v1/models` 与 `/v1/chat/completions` 仍都是 `403 permission_error`
+   - 这轮 provider 最终仍是 `completion_status=429`，说明剩余阻断是 MiniMax 官方 upstream rate limit，不是 probe key 语义再次混淆
 
 4. self_service 场景的 gateway probe 认证语义已经确认
    - 真实宿主的普通用户 gateway key 访问 `/v1/models` / `/v1/chat/completions` 时，使用的是 `Authorization: Bearer <gateway-key>`

docs/SOURCE_OF_TRUTH.md

@@ -162,6 +162,10 @@
 2. subscription 场景的 gateway probe 语义必须保持：
    - 最终 probe key 是宿主 managed key
    - 不是外部原始 `access_api_key`
+   - closure artifact 必须把“请求传入的 key”和“实际探测使用的 key”分开表达：
+     - `requested_probe_api_key` = 调用方传入原始 key
+     - `effective_probe_key_source=managed_subscription` = 实际 gateway probe 走宿主 managed key
+     - `probe_api_key` 仅继续保留给 `self_service` 向后兼容，不再用于 `subscription`
 
 3. 任何 live 结论都必须先确认：
    - 在线 CRM 进程启动时间
@@ -205,4 +209,5 @@
 - ❌ 把历史 PASS artifact 当当前 latest-head 真相
 - ❌ 把 `/v1/models` 通过当成 completion 已通过
 - ❌ 把 subscription 场景原始 `access_api_key` 当成最终 probe key
+- ❌ 把 `subscription` closure 里的 `requested_probe_api_key` 误读成实际 gateway probe key
 - ❌ 把 harness 参数错误（`PACK_PATH`、容器目标、probe auth）当成产品源码失败