chore(compose): update postgres to 18 and redis to 8

[basb7]

What does this change?

Bumps both datastores in compose.yml and compose.dev.yml to the current releases: postgres:16-alpine → postgres:18-alpine, redis:7-alpine → redis:8-alpine.

The Postgres bump is not just a tag change. Postgres 18 images moved the data directory to a major-version subdirectory:

Image	PGDATA
postgres:16-alpine	/var/lib/postgresql/data
postgres:18-alpine	/var/lib/postgresql/18/docker

The named volume is therefore mounted at the parent /var/lib/postgresql. Bumping only the tag would leave the data directory outside the volume, silently losing persistence. See docker-library/postgres#1259.

Redis licensing improves here. redis:7-alpine resolves to 7.4.x, which is dual RSALv2/SSPLv1 — only 7.2.4 and earlier were BSD 3-clause. Redis 8 is tri-licensed under RSALv2, SSPLv1 or AGPLv3, restoring an OSI-approved option. Flagward is MIT and consumes Redis as a separate network service, so the server's licence does not affect it.

Breaking change

Postgres volumes initialised by 16 cannot be read by 18 — the container refuses to start and asks for pg_upgrade. Existing volumes must be recreated:

docker compose -f compose.dev.yml down
docker volume rm flagward_postgres_data
docker compose -f compose.dev.yml up

In development this costs nothing: migrate and create_super_user run on startup. No deployments exist yet, so no upgrade path is documented.

How was it verified?

Full dev stack rebuilt from empty volumes:

• All four services report healthy
• select version() → PostgreSQL 18.6, PGDATA=/var/lib/postgresql/18/docker, PG_VERSION = 18
• redis-cli INFO server → redis_version:8.10.1
• 21 migrations applied, and still present after docker compose restart db — confirms the volume mount is correct
• GET /api/v1/health/ → 200, POST /api/v1/auth/login/ → 200, frontend → 307 (redirect to login)
• ruff check . clean, pytest 141 passed

Checklist

• Tests added or updated for this change — n/a, compose configuration only
• ruff check . passes
• pytest passes
• npm run lint and npm run build pass, if the frontend changed — n/a, frontend untouched
• Documentation updated, if behaviour changed
• Commits follow Conventional Commits