ComposeStop primitive (currently approximated by single-container Stop)

`Engine.Down` on a compose workspace handles `Remove: true` cleanly (calls `ComposeDown` → `docker compose down`). For `Remove: false` (stop without removing) we approximate by stopping just the primary service's container — sidecars stay running. Documented in down.go:

```go
// We approximate by stopping each container individually since
// our ComposeRuntime interface doesn't expose Stop separately.
```

### Plan

- Add `ComposeStop(ctx, ComposeStopSpec) error` to `runtime.ComposeRuntime`
- Implement in `runtime/docker/compose.go` via `docker compose stop` — no flags
- Update `down.go::downCompose` to call `ComposeStop` when `opts.Remove` is false
- Integration test: Up project → Down(no remove) → assert ALL services stopped, no containers removed

从 ComposeRuntime 接口和 runtime/docker/compose.go 开始，然后检查 down.go::downCompose 以及现有的 ComposeDown 路径。添加 ComposeStop 入口点，并为 Remove false 时先执行 Up 再执行 Down 添加集成覆盖。完成标准是使用 docker compose stop，并且所有服务都已停止而不会删除容器。

由索引模型根据 Issue 内容生成。