fix(cli-adapters): gemini/cursor/mtr 首轮 argv 无长度保护，同 #1250 的 tmux command too long 仍可复现 #1264

问题

#1251（7fd6fdcc9）已经给 OpenCode 加上 maxInitialPromptArgBytes: 8192，修好了 #1250 报的 command too long。但同一个成因在另外几个适配器上依然成立——它们同样把首轮内容烘进启动 argv，却都没有声明预算。

在最新 master（fd7c588ce）上枚举「argv 传首轮」的适配器，共 6 个：

gemini / cursor / mtr 三个是完全没有保护的：首轮信封（buildNewTopicPrompt）本身就占 ~5.8 KB，用户消息是净增在这之上的。

可达性（实测，非推断）

• tmux backend 不按 cliId 做限制，这几个适配器都能跑在上面；启动命令确实整条交给 tmux new-session（src/adapters/backend/tmux-backend.ts）。
• 本机 tmux 3.3a 实测上限，二分到 16256 B ~ 16384 B 之间（8 KB / 12 KB 通过，16 KB 起 command too long，与 fix(opencode): 长首轮提示词触发 tmux command too long #1250 现场一致）。
• ⟹ gemini / cursor / mtr 的用户消息余量约 10.4 KB。

触发难度：不是日常打字能达到的，但贴一段日志、堆栈、报错全文或一段代码就够——这正是 #1250 现场的形态。属于潜在但可达，不紧急。

⚠️ grok 要单独说：预算契约盖不住它

grok 声明了 injectsSessionContext: true，路由/身份信息不走位置参数，而是走 --rules（Claude --append-system-prompt 的同类）。实测：

• 完整 argv 5106 B，其中 --rules 负载 4990 B，位置参数（用户首轮）只有 53 B；
• 把首轮 prompt 整个拿掉之后，argv 仍有 5019 B —— 这是不可压缩的地板。

而 maxInitialPromptArgBytes 的语义只覆盖被 defer 的那个 prompt（见 shouldDeferInitialPromptForArgLimit），管不到 --rules。所以给 grok 加预算只能削掉那 53 B 的一半，几乎没用。grok 若要治，得单独讨论 --rules 负载怎么办（同理可能波及其他 injectsSessionContext 适配器），建议不要和下面的修一起做。

建议

1. 给 gemini / cursor / mtr 声明 maxInitialPromptArgBytes，复用 fix(opencode): 限制首轮 prompt argv 字节数，防止 tmux command too long #1251 已经跑通的既有 worker contract，一个适配器一行，超限自动走 post-start 输入队列。预算可对齐 OpenCode 的 8192（信封地板 ~5.8 KB，留 ~10 KB 余量仍在 tmux 上限内）。
2. 回归测试建议照抄 fix(opencode): 限制首轮 prompt argv 字节数，防止 tmux command too long #1251 的做法：用真实 buildNewTopicPrompt 构造信封（而不是手搓 fixture），这样将来谁把信封地板顶过预算，测试会真的红。
3. pi 已有自己的 4096 兜底，不需要改；grok 见上，单独立项。

备注

• fix(opencode): 长首轮提示词触发 tmux command too long #1250 目前仍是 open，但它描述的 OpenCode 那半已由 fix(opencode): 限制首轮 prompt argv 字节数，防止 tmux command too long #1251 修复，或许可以关掉，本 issue 接手剩下的面。
• 本 issue 由自动评审在 review fix(traex): 使用未截断首轮内容生成标题 #1244 时顺带发现（fix(traex): 使用未截断首轮内容生成标题 #1244 往 pi argv 里加了 --name，因此顺手核了一遍 argv 预算面；fix(traex): 使用未截断首轮内容生成标题 #1244 自身实测最坏 4809 B，安全）。以上数字均在 master fd7c588ce 上实测，最终以维护者判断为准。