Document MiniMax repeated probe behavior

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` 不是两个独立故障，而是同一条账号冷却链上的前后态
 
 ## 当前建议固化到后续文档/脚本的规则