docker-compose: Postgres 18 image rejects current data volume mount layout

[bigpuritz]

Background

docker-compose.yml declares:

```yaml
postgres:
image: postgres:18-alpine
...
volumes:
- pgdata:/var/lib/postgresql/data
```

Starting from Postgres 18, the official image rejects this mount layout and refuses to start with:

Error: in 18+, these Docker images are configured to store database data in a format which is compatible with `pg_ctlcluster` (specifically, using major-version-specific directory names).
Counter to that, there appears to be PostgreSQL data in: `/var/lib/postgresql/data` (unused mount/volume)
The suggested container configuration for 18+ is to place a single mount at `/var/lib/postgresql` …

This affects fresh starts as well as reuse of existing volumes — the local `docker compose up -d` workflow documented in the root `README.md` is broken.

Reproducer

```bash
docker compose down
docker volume rm examples_pgdata 2>/dev/null
docker compose up -d
docker logs examples-postgres-1 # → the error above
```

Discovered

While running the live smoke test for #6 (PR #7). Worked around locally with a non-committed `docker-compose.override.yml` pinning `postgres:17-alpine`.

Possible fixes

1. Pin `postgres:17-alpine` (defers the problem; PG 17 is supported until 2029).
2. Migrate the mount to the Postgres 18 layout: `pgdata:/var/lib/postgresql`. Existing local volumes will need to be re-created (acceptable in this dev-only setup).

Option 2 is the long-term fix; option 1 is fine if we want to avoid touching dev volumes today.

Acceptance criteria

• `docker compose up -d` from the repo root starts cleanly on a machine without any pre-existing Plugwerk volumes.
• `curl http://localhost:8080/actuator/health\` returns `{"status":"UP"}` after the health check passes.
• `README.md` quick-start section still works as written.