Track a future SandboxOperator for sandboxed command/job execution

## Scope This issue tracks a **future `SandboxOperator`** (and a `@task.sandbox` decorator) — an Airflow *task* that runs one author-defined command or job in an isolated, ephemeral sandbox. It complements the sandboxed-execution surfaces already in flight and is opened to keep the roadmap explicit and the boundaries clear; **no implementation is proposed here yet.** ## Where it sits These are separate execution boundaries, not one API and not a monotonic security ranking: | Surface | What runs in the sandbox | Tracked by | |---|---|---| | Restricted code orchestration | Monty-compatible glue code | #68407 (merged) | | Sandboxed code execution as a tool | model-generated full Python; the agent stays outside | #68847 | | **Sandboxed command/job execution** | **one author-defined command or job** | **this issue** | | Sandboxed TaskInstance execution | the complete Task SDK `ExecuteTask` workload | #68845 | ## What a `SandboxOperator` would add over the toolset (#68847) The toolset gives an *agent* a `run_python_in_sandbox` tool inside a single task. A `SandboxOperator` would instead *be* the task and own a real task lifecycle: - author-declared command / image / inputs; - file and artifact upload and download; - cancellation and, ideally, deferrable/resumable execution that frees the worker slot while the sandbox runs; - streamed and reconnectable logs. It would reuse the same sandbox code-execution adapters where practical, but its contract is a task lifecycle, not a code-execution adapter — and it is explicitly **not** an executor (that whole-task surface is tracked separately in #68845). ## Status Future work; no implementation planned yet. Opened so the roadmap is fully issue-backed and the scope boundaries between the tool, operator, and executor layers stay explicit. --- Drafted-by: Claude Code (Opus 4.8) (no human review before posting)