docs(real-host): narrow completion blocker root causes

docs/REAL_HOST_ACCEPTANCE_LEARNINGS.md

@@ -207,11 +207,46 @@
 - channel 是否同时具备 `model_mapping + model_pricing + restrict_models + billing_model_source=channel_mapped`
 - 是否误打到了旧 CRM 进程
 
-### 现象 C：`/v1/models` 已 200，但 `/v1/chat/completions` 返回 502
+### 现象 C：`/v1/models` 已 200，但 `/v1/chat/completions` 失败
 优先判断：
-- host 侧 provider 兼容性问题
-- 上游 provider key/quota 问题
-- 不要再把问题回退归因为 CRM 导入或 access closure
+- host provider 兼容性
+- 上游 key/quota
+- 不要先回退归因为 CRM 导入失败
+
+### 进一步缩圈：DeepSeek `chat/completions` 当前更像宿主兼容层问题，而不是 key 失效
+
+2026-05-21 新增的直接证据链：
+
+1. managed key 直打 fresh host 仍稳定失败
+   - `http://127.0.0.1:18097/v1/models` = `HTTP 200`
+   - `http://127.0.0.1:18097/v1/chat/completions` = `HTTP 502`
+   - 说明普通用户 / subscription / key / group 绑定链路不是这一步的主阻断
+
+2. 同一台 remote43 主机直打 upstream 反而成功
+   - 对 `https://aitoken.quanfuli.cn/v1/chat/completions`
+   - 使用同一 upstream key、同一 `deepseek-v4-flash` payload
+   - 返回 `HTTP 200`
+   - 但响应 `Content-Type` 是 `text/event-stream`
+
+3. fresh-host app 日志显示 host chat 会在一组重复 DeepSeek accounts 间 failover，全部记成 `account_upstream_error 500/502`
+   - 当前 group `5` 里有 10 个 active DeepSeek accounts：`14,15,16,17,19,20,23,25,26,28`
+   - 它们 `credentials.api_key/base_url/model_mapping` 相同
+   - 请求并不是命中一个固定坏 account，而是在重复 account 集合中轮流失败
+
+当前最合理的解释：
+- DeepSeek 这条 completion 阻断已经缩到“宿主 chat 上游兼容/解析层”
+- 不是 CRM 没把模型、channel、subscription、managed key 准备好
+- 重复 account 不是唯一根因，但会把一次失败放大成整组 failover 噪音，增加生产不稳定性
+
+### 进一步缩圈：MiniMax 当前是 quota 阻断，不是 CRM 路由阻断
+
+1. managed key 视角 `/v1/models` 已 200
+2. upstream 直探 `/chat/completions` = `403 insufficient_user_quota`
+3. fresh-host group `6` 内 6 个 active MiniMax accounts 的 `temp_unschedulable_reason` 都明确记录了 `insufficient_user_quota`
+
+因此：
+- MiniMax 当前要解的是“换可用 key / 补额度”
+- 不应继续把它归因为 CRM import/access 逻辑失败
 
 ## 当前建议固化到后续文档/脚本的规则