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

Start with the ComposeRuntime interface and runtime/docker/compose.go, then inspect down.go::downCompose and the existing ComposeDown path. Add the ComposeStop entry point and integration coverage for Up followed by Down with Remove false. Done means docker compose stop is used and all services are stopped without removing containers.

Written by the indexing model from the issue text.