v1.2.1

上游错误按官方客户端的错误码表重新归类，国际版 deepseek 不再因为一次「模型繁忙」整号停十分钟；客户端发来的压缩请求体也能正常处理了。

变更

• 上游错误先看业务码再看状态码和文案，码表和归类照官方客户端（内置 CLI 的错误码枚举），对照见官方客户端对照 · 错误码：
  • 14003「模型繁忙」和每秒、每分钟限额（6001 6002 6005 6006）没给重置时间时，只冷却这个号的这个模型约 30 秒，当场换号重试。以前落进通用 429，整个号冷却约 10 分钟：10-20 生产上两个国际版号各撞一次 14003 就全停了。所有号的这个模型都在冷却时回 429 并带 Retry-After，客户端稍等重试即可；
  • 按模型限额从只认 6004 扩到 6000–6008，冷却到上游给的重置时间，换别的模型照样可用；
  • 额度用完的业务码（14001 14012 14013 14014 14019，以前只认 14018）按余额不足冷却到次日 04:00，不再冷却十分钟后又被选中；
  • 14015（授权过期）、14016（企业未激活）按账号故障软冷却，原因里带业务码；10105（同时进行的会话太多）账号冷却约 60 秒；
  • 流式回复中途的错误帧同样按业务码处置；
  • 错误响应的 gateway_hint 按业务码细分：模型繁忙、按模型限额、会话太多各有说明。
• 上下文超限按官方的词表认各家模型供应商的说法（maximum context length、Input length too long、413 Request Entity Too Large 等），不罚账号、不换号、原文返回；以前只认 11115 和 prompt is too long，其余的会被当成限流或普通错误换号重试。

修复

• 客户端发来压缩过的请求体（Content-Encoding 为 gzip、deflate、br、zstd，或没标头但内容是 gzip）时网关先解开再处理。以前原样转给上游，上游回 11101（invalid character '\x1f'），生产 10-19 至 10-20 有四十多次。解不开或不是合法 JSON 的请求在网关就回 400，不再打上游。

---

• Docker 镜像：ghcr.io/yreidev/workbuddy2api-panel:1.2.1（同一镜像还有 1.2、1 标签）
• 升级方法：见部署与运维
• 校验：sha256sum -c --ignore-missing checksums.txt
• 完整变更：v1.2.0...v1.2.1