v2.1.12 修正循环保护的压制上限，让重发真正生效

变更

修复：循环保护的重发几乎没机会触发。

Devin 那把密钥反复断流，根因不是「没做重试」，而是重试的触发条件几乎不可能满足。推理侧的压制有两条上限：字符上限 40000、字节上限 2 MiB。线上上游把推理切成约 220 字节的小帧、每帧只带一两个字符（实测 124–222 字节/字符），于是 2 MiB 只折合一万多字符。缓冲会在 256 行窗口凑满、重复覆盖达标之前就被放行——客户端先看到一屏重复文本、再收到 422，同账号重发这条路径根本没走到。

48 小时里 39 次循环判定只有 13 次走到了重发，其余 26 次都从这里漏掉。

现在字节上限提到 16 MiB（覆盖 65536 字符 × 222 字节 ≈ 14 MB），字符上限提到 65536（实测判定点落在 9439–55777）。字符与时间上限成为真正的绑定条件，不再被字节上限抢先。

顺带修复：走 Chat Completions 的客户端拿不到运行约定。

Devin、narrafork 调用的是 /v1/chat/completions，而「别说完就停」这条运行约定此前只挂在 /v1/responses 上。结果模型回一句「让我先确认一下…」就结束本轮，客户端不会自动续跑，用户只能反复手动发「继续」。现在两条路径都会注入，并按请求体里实际的 tools/functions 声明判断是否带工具；纯对话不注入，Responses 路径不会重复注入。

部署

热更新即可，不需要重建容器：

docker compose pull
docker compose up -d

已知边界

保护仍是启发式：合法的重复短行可能误报，无换行的循环不在覆盖范围。业务本来就需要大量重复短行时，可以按密钥关闭这项保护。

压制期间每条在途请求最多占用 16 MiB 内存。峰值并发实测约 7 条在途请求，按每条上限计约 112 MB；即便 24 账号 × 单账号 3 在途全部占满（72 条）也在 1.2 GB 以内。

运行约定是提示层的缓解措施，不是启发式重试，也不能保证第三方模型在每次长会话里都完成任务。