Document MiniMax repeated probe behavior

docs/EXECUTION_BOARD.md

@@ -200,6 +200,11 @@
     - `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 可用
+  - 同一 fresh-host 上继续补的 MiniMax `M2.5` 缩圈验证已证明：
+    - `artifacts/real-host-acceptance/20260523_local_clean_minimax_m25_only_probe`：单独只打 `M2.5` 时，宿主会选中真实账号并命中 upstream `429`
+    - `artifacts/real-host-acceptance/20260523_local_clean_minimax_m25_repeated_probe`：连续第 1 次 `M2.5` 是 `429`，后续第 2/3 次退化成 `503 Service temporarily unavailable`
+    - 对应宿主日志中，第一次有 `account_id=1` 和 `upstream_status=429`，后续只有 `account_select_failed error=\"no available accounts\"`
+    - 当前 MiniMax live 阻断要按两层解释：第一次是 upstream quota/rate-limit，后续 `503` 是唯一账号进入临时不可调度窗口后的宿主侧结果
 
 **本轮实现状态（T1 ~ T13）**：
 - [x] `internal/batch` canonical types / reuse policy / service / confirmation / validation / projection 已落地

docs/REAL_HOST_ACCEPTANCE_LEARNINGS.md

@@ -42,6 +42,12 @@
      - 不再出现 legacy `probe_api_key`
      - 同一轮 raw key 直打宿主 `/v1/models` 与 `/v1/chat/completions` 仍都是 `403 permission_error`
    - 这轮 provider 最终仍是 `completion_status=429`，说明剩余阻断是 MiniMax 官方 upstream rate limit，不是 probe key 语义再次混淆
+   - 继续在同一 fresh-host 上补的 MiniMax `M2.5` 缩圈验证，已经把 `429 -> 503` 的因果链单独坐实：
+     - 单独只打一条 `MiniMax-M2.5-highspeed` 时，真实结果是 upstream `429`，见 `artifacts/real-host-acceptance/20260523_local_clean_minimax_m25_only_probe`
+     - 连续第 1 次打 `M2.5` 时仍是 `429`
+     - 紧接着第 2 次、第 3 次再打同一模型，会变成宿主 `503 Service temporarily unavailable`
+     - 对应宿主日志显示：第一次有 `account_id=1` 和 `upstream_status=429`，后两次只剩 `account_select_failed error=\"no available accounts\"`
+     - 因此 `M2.5` 的 `503` 不是模型自身固定返回 `503`，而是唯一账号被前一次 `429` 打进临时不可调度窗口后的宿主侧结果，见 `artifacts/real-host-acceptance/20260523_local_clean_minimax_m25_repeated_probe`
 
 4. self_service 场景的 gateway probe 认证语义已经确认
    - 真实宿主的普通用户 gateway key 访问 `/v1/models` / `/v1/chat/completions` 时，使用的是 `Authorization: Bearer <gateway-key>`
@@ -373,6 +379,10 @@
 因此：
 - MiniMax 当前要解的是“换可用 key / 补额度”
 - 不应继续把它归因为 CRM import/access 逻辑失败
+- 而且要区分两层失败：
+  - 第一次 completion 失败是真实 upstream `429 insufficient_user_quota / rate_limit`
+  - 同一账号冷却窗口内的后续 completion 失败，可能退化成宿主 `503 no available accounts`
+- `20260523_local_clean_minimax_m25_only_probe` 与 `20260523_local_clean_minimax_m25_repeated_probe` 已证明：`429` 和后续 `503` 不是两个独立故障，而是同一条账号冷却链上的前后态
 
 ## 当前建议固化到后续文档/脚本的规则