feat: add runner tran passthrough

docs/reference/code-queue-supervision.md

@@ -407,7 +407,7 @@ Code Queue task 不是只要 push 代码就算完成。
 - WebUI 和 CLI 的 proxy 路径不一致；
 - deploy job 报失败但服务 API 实际健康；
 - 指挥侧突发 submit 打满 Code Queue manager 或低内存主机，导致队列还没确认任务就被压垮；
-- Code Queue 容器缺少监督所需的基础工具或凭证路径，例如 `gh`、`hub` 或 GitHub token 注入路径。
+- Code Queue 容器缺少监督所需的基础工具或凭证路径，例如 `gh`、`hub`、`tran` 或 GitHub token 注入路径。
 - D601、provider-gateway、registry、k3sctl-adapter 或 service proxy 的单路径瞬时失败被 worker 放大为全局阻塞，而缺少多信号健康裁决和可重试错误分类。
 - runner、provider 或目标 runtime 缺少 Secret/env 注入、DNS、egress、registry auth、GitHub auth 或受控 rollout 权限，导致业务任务无法通过常规路径完成。
 
@@ -415,6 +415,8 @@ Code Queue task 不是只要 push 代码就算完成。
 
 如果缺陷只存在于 Code Queue 执行环境，且服务可以在 dev 中安全热修而不触碰 prod，应先做最小临时 live remedy。然后把修复持久化到相关 Dockerfile、容器镜像或凭证传播路径，并在 dev 验证持久化修复后再关闭问题。
 
+Code Queue runner 的分布式访问能力必须通过镜像内 `/usr/local/bin/tran` 固化，而不是依赖临时拷贝脚本或手工记忆命令前缀。runner 内 `tran` 走公网 frontend 控制面和 `/api/dispatch`，不要求 runner pod 持有 provider token，也不要求 runner pod 能解析 backend-core 集群内 DNS；因此当 runner-local DNS/Secret 缺失而 frontend dispatch 仍可用时，应判为可恢复的 runner-local observation gap。runner 环境中的 remote frontend HTTP 读写默认使用 `curl` 后端，以降低部分 runner 上 Bun HTTP body 读取 native crash 的风险；这不是绕过控制面，route parser 和 dispatch payload 仍由 UniDesk CLI 生成。当前必需验收目标是 D601 的真实 Code Queue pod：至少执行 `tran D601 argv ...`、`tran G14 argv ...` 以及一个 `tran <provider>:k3s ...` 只读命令，证明 D601 runner 能跨 provider host 与 k3s route 透传。G14 runner 可作为后续兼容性观察，不作为该合同当前阻塞条件。
+
 如果业务任务发现缺少工具、Secret/env、DNS、egress 或凭证路径，指挥官应把它拆成独立 infra task，并标记为 `runnerDisposition=infra-blocked` 或等价基础设施阻塞，而不是埋在业务任务 prompt 中。业务 runner 不应自行摸索 live Secret、打印 env/token、复制凭证命令、扩大网络出口或通过反复 rollout 猜测问题；它只能提交脱敏证据、说明缺失能力和等待指挥官或 infra lane 处理。业务任务在 bridge 存在时应继续推进。
 
 Artifact publish preflight 也属于基础设施问题的只读分类范畴：`artifact-registry status|health` 和 `ci publish-user-service --dry-run` 返回 `runnerDisposition=infra-blocked` 时，通常说明 backend-core/database/provider 通道缺失，而不是用户服务本身的业务错误。此时应先恢复控制通道，再决定是否重试，不要把裸 `No such container` 当成可直接回归的业务失败。