[FEATURE] Support multi-container (Docker Compose) jobs via ComposeJobConfig

## 背景

ROCK SDK 的 Job 体系目前支持 BashJobConfig（单脚本）和 HarborJobConfig（harbor benchmark），但缺少**多容器编排**能力。许多真实任务（如 claude-code SWE rollout）需要主容器 + sidecar（proxy/eval）+ init 容器协作，目前只能在 Agent-Platform 侧用 K8s Pod 实现。

## 需求

为 ROCK SDK 增加 `ComposeJobConfig`，把多容器（Docker Compose）能力下沉为 SDK 一等公民：

1. **主容器**：入口脚本（继承 BashJobConfig 的 `script_path`）
2. **Sidecar 容器**：与主容器并行（proxy、eval 等），各有独立 image/script/resources
3. **Init 容器**：主容器前串行执行的初始化任务
4. **OSS 依赖下载**、**Secret 注入**、**资源声明**（request/limit）
5. **DinD 模式**：所有容器在一个 DinD 沙箱内，由生成的 runner.sh 通过 docker CLI 编排

## 设计约束

- 必须继承 BashJobConfig 的 `script_path` + `environment` 结构，Compose 能力放顶层 `compose` 块（与 environment 平级，区分 DinD 外层沙箱 vs 内层容器两个层次）
- 复用已有 EnvironmentConfig / OssMirrorConfig 等字段，不重复定义
- `from_yaml` 通过 `compose` 键检测类型，不破坏现有 Bash/Harbor 检测

## 验收

- ComposeJobConfig + ComposeTrial 实现 + 单元测试
- 端到端：用 ComposeJobConfig 在真实 ROCK 后端跑通一个多容器 harbor 任务

Start by reading the existing BashJobConfig and from_yaml type-detection paths, then trace how a ComposeJobConfig and ComposeTrial would connect to the generated runner.sh. Review the existing EnvironmentConfig and OssMirrorConfig structures before defining the compose block. Done means unit tests cover detection and configuration, and a real ROCK backend runs a multi-container Harbor task end to end.

Written by the indexing model from the issue text.