ACK OMP Worker 支持规格

目标

让 ACK 的 Developer/Test worker 可以通过当前 Oh My Pi（OMP）CLI 工作，同时保留现有的角色路由、模型 allowlist、审批模式、worktree 和 receipt 校验边界。

ACK worker CLI allowlist 增加 omp，不增加 opencode。
增加 OMP 的模型 allowlist 与 role/profile 配置能力；模型使用 OMP 要求的精确 provider/model 选择器，例如 opencode-go/gpt-5.6-luna，不从当前 Coordinator 会话自动推断。
launcher 在固定可信目录中解析 omp，探测并记录版本，生成确定性的启动 argv，并把 CLI、模型、thinking、审批模式、worktree 和版本纳入 fingerprint/receipt。
OMP worker 使用交互式 omp 命令，通过结构化参数指定模型、thinking、approval mode 和工作目录；Orca 仍负责 terminal orchestration 与任务 dispatch。
OMP profile 不允许写入自由 command、额外 argv、shell、环境变量或凭据值；不使用 --auto-approve、--plan-yolo 或会话复用；--approval-mode yolo 是 OMP workspace-write worker 的默认审批模式，规则层直接允许。
为 OMP 增加 profile 校验、argv 渲染、环境凭据隔离、可信 executable 解析和 launcher plan 的白盒/黑盒测试。
保持 Codex、Cursor、Grok 既有行为不变；不修改 ACK 的三角色职责或 delivery 流程。

omp 可执行文件必须通过 ACK 固定可信目录解析，不能从调用者 PATH 任意拾取。
OMP 模型 ID 必须由项目 allowlist 明确声明；当前会话中的 opencode-go/gpt-5.6-luna 只有在 profile 明确配置后才可使用。
审批模式由 launcher 固定构造：workspace-write → --approval-mode yolo、read-only → --approval-mode always-ask。
workspace-write 下的 exec 工具是否会因 OMP 审批提示阻塞，由独立 Test 在黑盒环境中验证；若阻塞，必须记录为环境/运行模式问题，不伪报成功。

validate_orchestration 接受合法 omp profile，拒绝未知 CLI、未在 omp/role/tier allowlist 中的模型、Test strong profile 和危险权限模式。
render_worker_argv 对 OMP 只生成固定的 omp --model {provider/model} --thinking {level} --approval-mode {mode} --cwd {absolute-worktree} --no-session 形状，并拒绝危险或会话复用参数。
resolve_executable/launcher plan 能在可信 OMP 安装下记录 cli: omp、版本、精确 argv、环境策略和 worktree identity；非可信同名 executable fail closed。
OMP worker 环境只获得基础运行时变量、代理/证书变量和明确允许的 OMP/provider credential 名称，不继承调用者的任意环境变量、PATH 或其它 CLI 凭据。
现有 Codex/Cursor/Grok profile 的 argv、allowlist、权限拒绝和 receipt 校验回归测试继续通过。
在独立临时项目和隔离 OMP 配置目录中，Test 能确认 fresh OMP worker 被正确绑定到指定 worktree，能接收 Orca dispatch 的任务输入，并能回报 ACK lifecycle 证据；无法完成时记录具体协议/环境证据。
文档明确：OMP 是 worker CLI，Orca 是编排层；两者都不自行决定模型，模型由 tasks.yaml.project.orchestration profile 决定。