ConfigRenderer::render_compose omits top-level volumes: block, breaking services with named volumes (same class as #211)

[vsilent]

Summary

Same root-cause class as #211 (which was just fixed for networks): the server-side compose renderer emits a volumes: mapping under a service (e.g. postgres_data:/var/lib/postgresql/data) but never emits the corresponding top-level volumes: declaration block, making the generated compose invalid.

Steps to reproduce

1. Deploy a project with a service that declares a named volume, e.g. miniflux's stacker.yml:

   services:
     - name: postgres
       image: postgres:16-alpine
       volumes:
         - postgres_data:/var/lib/postgresql/data
   volumes:
     postgres_data: {}

2. stacker deploy --target cloud --key <key> --force-new --watch (completes fine — this uses the CLI-generated compose, not the server-rendered one)
3. stacker agent deploy-app miniflux --image miniflux/miniflux:latest --force
4. Fails:

   Error: Agent command '...' failed: Image pull had issues (continuing): ...
   service "postgres" refers to undefined volume postgres_data: invalid compose project (pull_warning)
   

Confirmed via remote compose file

/home/trydirect/project/docker-compose.yml on the target server, freshly rendered at the time of the failing command:

  postgres:
    ...
    volumes:
      - postgres_data:/var/lib/postgresql/data
    networks:
      - default_network
    ...

networks:
  default_network:
    driver: bridge

Note networks: top-level block is present and correct (the #211 fix working as intended) — but there is no top-level volumes: block at all, even though postgres_data is referenced by the service.

Expected

Same fix pattern as #211: the top-level volumes: block should be derived from the named volumes actually referenced by services, so it never diverges from what's referenced.

Environment

• stacker CLI 0.3.1 (144d1a6)
• Found immediately after re-verifying Remote compose references undefined network default_network #211 was fixed — the network fix uncovered this sibling bug in the same render path (ConfigRenderer::render_compose), which previously errored out on the network mismatch before ever reaching the volumes-rendering step.
• Reproduced via stacker-projects/miniflux in trydirect/stacker-project-examples

[vsilent]

Confirmed — same root-cause class as #211, this time for volumes. Fixed in ConfigRenderer::render_compose (src/services/config_renderer.rs):

• Added is_named_volume() to distinguish a named-volume reference (e.g. postgres_data) from a bind mount (paths starting with ., /, or ~), which Compose does not declare under top-level volumes:.
• render_compose now collects the distinct named volumes actually referenced across all services and passes them to the template as named_volumes.
• The template now emits a top-level volumes: block for exactly those names — omitted entirely when no service uses a named volume, so nothing changes for stacks without one.

Two new tests:

• render_compose_declares_named_volumes_referenced_by_services — a postgres service with both a named volume (postgres_data) and a bind mount (./config) renders a top-level volumes: block containing postgres_data and not ./config.
• render_compose_omits_volumes_block_when_no_named_volumes — no named volume anywhere → no top-level volumes: key.

Full suite: 1772 passed, 0 failed.

Not committed yet — leaving that to the repo owner, as with #211.

[vsilent]

Confirmed fixed — re-tested same session as #211's fix. Remote compose for `miniflux` now has the top-level `volumes:` block:
```yaml
volumes:
- postgres_data:/var/lib/postgresql/data
...
volumes:
postgres_data:
```
`stacker agent deploy-app` no longer errors on the undefined-volume check. Thanks!

Found one more in the same area while checking the redeployed container actually came up healthy — filed as #237 (network isolation, not a rendering syntax error this time).