feat(code-queue): register minimax-m3 alongside minimax-m2.7

Add minimax-m3 as a sibling model on the same path as the existing
minimax-m2.7 support. M3 is the new PROD default; M2.7 remains available
as a one-line rollback target via MINIMAX_MODEL.

Changes:
- code-agent/common.ts: add minimaxM3Model constant, include in
  defaultCodeModels, normalize aliases (minimax-m3 / m3), route to
  opencode port, sibling entry in codeModelProviderSourceContract.
- code-agent/opencode.ts: add M3 branch in openCodeModelId, register
  both M2.7 and M3 in openCodeConfigContent, inject MINIMAX_M3_MODEL
  in local/remote env, M3 branch in missingOpenCodeCredentialMessage.
- index.ts + types.ts: add minimaxM3Model to RuntimeConfig, read
  MINIMAX_M3_MODEL env, propagate to remoteCodexEnvKeys.
- queue-api.ts: include minimaxM3Model in Pick for
  codeModelProviderSourceContract callers.
- scripts/src/code-queue.ts: add minimaxM3SubmitModel, normalize/port
  routing, default route recommendation now points to M3, M2.7 kept
  as minimaxM2FallbackCandidate.
- scripts/src/docker.ts: default UNIDESK_CODE_QUEUE_MINIMAX_M3_MODEL
  to MiniMax-M3.
- k8s yaml (D601 + G14): CODE_QUEUE_MODELS gains minimax-m3, three
  deployments each set MINIMAX_MODEL=MiniMax-M3 and
  MINIMAX_M3_MODEL=MiniMax-M3.
- docker-compose.d601.yml: same env defaults for local compose.
- docs/reference/{code-queue-supervision,microservices,
  windows-passthrough}.md: update model contracts to M3 default +
  M2.7 fallback.
- scripts/code-queue-submit-routing-contract-test.ts: low-risk
  recommendation now asserts minimax-m3; registry asserts both M3
  and M2.7 fallback in modelPorts/opencodeModels; provider source
  contract test passes minimaxM3Model.

Refs: #189

docs/reference/code-queue-supervision.md

@@ -96,9 +96,9 @@ Code Queue 派单模型按成本、可信度和 blast radius 分层：GPT-5.5/Co
 当前提交合同由 `bun scripts/cli.ts codex submit` 暴露：prompt 必须来自位置参数、`--prompt-file` 或 `--prompt-stdin`；可选字段包括 `--queue/--queue-id`、`--provider-id/--provider`、`--cwd/--workdir`、`--model`、`--reasoning-effort`、`--execution-mode/--mode`、`--max-attempts` 和 `--reference-task-id/--reference/--ref`。长 prompt、多行 prompt、含引号/反引号/Markdown 表格/JSON/反斜杠的 prompt 应使用 `--prompt-stdin` 或 `--prompt-file`，例如 `cat <<'PROMPT' | bun scripts/cli.ts codex submit --prompt-stdin --queue <id> --dry-run` 或 `bun scripts/cli.ts codex submit --prompt-file /tmp/code-queue-prompt.md --queue <id> --dry-run`；位置参数只适合短单行 smoke prompt。提交前先用 `--dry-run` 检查完整 payload，确认后移除 `--dry-run`。`--execution-mode` 只表示 Code Queue runtime placement，有效值是 `default` 与 `windows-native`；像 `full-access` 这类 sandbox-like 值必须在 response 中显示 requested/effective mapping，并提示真实权限看服务级 `runnerPermissions.sandbox` / `approvalPolicy`，当前不支持每任务 sandbox override。真实提交成功只返回低噪声写入确认、task id、队列和后续查看命令，必须标记 `promptOmitted=true` 且不得回显 prompt；需要复核正文时用返回的 `codex task <taskId>` 渐进展开。这些字段写入任务 payload 后由 `code-queue-mgr` 入 PostgreSQL，核心任务字段包括 `queue_id`、`provider_id`、`execution_mode`、`model`、`cwd`、`prompt/base_prompt`、`reference_task_ids`、`reasoning_effort`、`max_attempts` 和 `task_json`；`task_json` 还保留 `requestedExecutionMode` 以便审计 requested/effective 差异；队列记录至少有 `id/name/created_at/updated_at`。模型治理应优先看任务 payload 和数据库字段，不靠 worker final response 自报。
 真实 `codex submit` 确认输出的 `queue` 是低噪声监督摘要：`queuedTaskIds.items` 必须强制包含本次新建且仍为 queued/retry_wait 的任务 ID；`activeTaskIds` 在主 server 控制面 `activeTaskIds=[]` 但 `counts.running/judging>0` 时必须回退到 PostgreSQL `databaseActiveTaskIds` 或执行诊断中的 active IDs；这些 ID 列表都只能作为带 `count/returned/omitted/truncated/source` 的有界预览，权威并发口径来自 `counts` 和 `countContext`。当预览没有展开所有 ID 时，`listPreviewPolicy` 必须明确说明 omitted counts 和 raw 查看命令，避免指挥侧误判 15-runner 目标。
 
-运行态默认模型仍是 `gpt-5.5`。`CODE_QUEUE_MODELS` 当前长期合同至少包含 GPT-5.5、GPT-5.4、GPT-5.4 Mini、DeepSeek Chat 和 MiniMax M2.7；`deepseek`/`deepseek-chat` 与 `minimax-m2.7` 会走 OpenCode port，其余模型走 Codex port。只有当执行面 `/health` 或等价配置已经显示 DeepSeek 模型可用、并完成轻量 runner smoke 后，才允许真实提交 `--model deepseek-chat`。
+运行态默认模型仍是 `gpt-5.5`。`CODE_QUEUE_MODELS` 当前长期合同至少包含 GPT-5.5、GPT-5.4、GPT-5.4 Mini、DeepSeek Chat、MiniMax M3（生产默认）和 MiniMax M2.7（回滚）；`deepseek`/`deepseek-chat`、`minimax-m3` 与 `minimax-m2.7` 会走 OpenCode port，其余模型走 Codex port。PROD 集群把 `MINIMAX_MODEL` 切到 `MiniMax-M3`，judge 与 opencode 跟随；M2.7 路径完整保留，回滚只需 `MINIMAX_MODEL=MiniMax-M2.7` + rollout restart。只有当执行面 `/health` 或等价配置已经显示 DeepSeek 模型可用、并完成轻量 runner smoke 后，才允许真实提交 `--model deepseek-chat`。
 
-`codex submit --dry-run` 是派单前的轻量 preflight。它输出 `routingRecommendation`、`policyContract` 和模型注册表，帮助指挥官看到推荐 runner/model、风险信号、缺失的 prompt guard、模型分层、并发上限、`opencodeModels` 和 `modelPorts`；它不会修改真实提交 payload，也不会替代指挥官判断。真实派单是否使用 `--model minimax-m2.7`、`--model deepseek-chat` 或 `--model gpt-5.5` 仍由指挥官显式决定。
+`codex submit --dry-run` 是派单前的轻量 preflight。它输出 `routingRecommendation`、`policyContract` 和模型注册表，帮助指挥官看到推荐 runner/model、风险信号、缺失的 prompt guard、模型分层、并发上限、`opencodeModels` 和 `modelPorts`；它不会修改真实提交 payload，也不会替代指挥官判断。真实派单是否使用 `--model minimax-m3`、`--model minimax-m2.7`、`--model deepseek-chat` 或 `--model gpt-5.5` 仍由指挥官显式决定。
 
 `codex prompt-lint [prompt|--prompt-file path|--prompt-stdin]` 是同一套派单前 guardrail 的本地 dry-run 入口，用于检查 runner prompt 是否声明了 `DEV test class`、是否列出允许的 live mutation、禁止动作和 closeout 字段。它只返回分类、缺失或矛盾项和有界 evidence，不提交任务、不连接 live service、不打印完整 prompt。`codex submit --dry-run` 和 `codex steer --dry-run` 会嵌入同一 `promptLint` 结果；`dispatchDisposition=needs-authorization` 时，指挥官必须补齐授权或把 prompt 降到 `read-only` 范围后再派发/steer。
 
@@ -114,7 +114,7 @@ Device Pod 类 DS 验收不能只看最终回复。指挥官必须用 `codex tas
 | --- | --- | --- | --- |
 | GPT-5.5/Codex | 高风险、复杂、跨模块、运行态、CI/CD、release、deploy、安全、最终质量裁决 | 多信号诊断、可回滚边界、必要的轻量或 dev 验证 | 不因成本把运行态和生产风险降级 |
 | DeepSeek/OpenCode | 中等复杂度的前端功能、局部用户服务模块、局部 CLI/helper、明确 contract guard 或 unit test | prompt 自包含、写入范围窄、无生产/密钥/DB 写入、验证命令明确、指挥官审阅 | 不处理 Code Queue runtime、backend-core、provider-gateway、k3sctl-adapter、release/v1 或部署变更 |
-| MiniMax/OpenCode | 只读调查、文档、简单前端/样式、低风险样板、轻量 dry-run/preflight 和小范围测试补齐 | issue 只作辅助引用、必须给出 diff/路径/命令证据、完成后保持未读待审 | 不处理共享核心、隐式远端状态、生产、密钥、DB、重启、复杂 bug 或最终裁决 |
+| MiniMax/OpenCode (M3 默认 / M2.7 回滚) | 只读调查、文档、简单前端/样式、低风险样板、轻量 dry-run/preflight 和小范围测试补齐 | issue 只作辅助引用、必须给出 diff/路径/命令证据、完成后保持未读待审 | 不处理共享核心、隐式远端状态、生产、密钥、DB、重启、复杂 bug 或最终裁决 |
 | 指挥官/人工 | 真实生产动作、运行中任务控制、密钥/数据库/破坏性 Git、批量已读和高风险恢复 | 用户授权、只读诊断、恢复方案、记录 issue/#20/#24 | 不把执行权交给普通 worker |
 
 外部 token provider、模型 API 和上游服务限流遵循本文监控章节的退避规则；`policyContract.externalProvider429` 只是把同一规则暴露给 dry-run 调度判断。