chore(deps): postgres 18, and the data directory it now insists on

[JArmandoAnaya]

Supersedes #477, which bumps the tag alone. That bump takes the postgres profile down, and no required check can see it: the service sits behind a profile, and nothing in CI starts it.

What changed

• docker/compose.yaml — postgres:16 → postgres:18, and the volume mount moves from /var/lib/postgresql/data up one level to /var/lib/postgresql, with a comment carrying the reason.
• .agents/skills/infra/docker-dev/SKILL.md — the symptom and the way out, next to the command that produces it.

Why the mount has to move with the tag

From 18 the image stores its cluster in a major-version subdirectory (PGDATA=/var/lib/postgresql/18/docker) and declares its volume at /var/lib/postgresql. Its entrypoint refuses to start — exit 1, before a single server line — when it finds a mount on the old path. Measured here on postgres:18 (18.4), with the mount this repository had:

Error: in 18+, these Docker images are configured to store database data in a
       format which is compatible with "pg_ctlcluster" ...
       Counter to that, there appears to be PostgreSQL data in:
         /var/lib/postgresql/data (unused mount/volume)

It fires on an empty volume too, so the tag bump alone is not "breaks on upgrade" — it is "does not start", for everybody.

An existing volume is not adopted

A cluster written by 16 is unreadable to 18 wherever it is mounted; the same refusal fires with the volume moved to the new path. There is nothing to preserve — the compose file already records that this service is wired to nothing, no code reads a DATABASE_URL — so docker volume rm visionset_postgres-data is the documented way through, and that is what the skill now says.

Test plan

Against the real compose file in this branch, --profile postgres:

• docker compose config resolves to postgres:18 with the single mount postgres-data → /var/lib/postgresql.
• The service starts, and answers: PostgreSQL 18.4 (Debian 18.4-1.pgdg13+1).
• Persistence through the named volume: wrote a row, restart, read it back. The cluster lands in 18/docker inside visionset_postgres-data.
• The two negative cases above were each reproduced before the fix, on a fresh volume and on a 16-seeded one.

Static gates, all exit 0: ruff check ., ruff format --check ., lint-imports (4 kept, 0 broken), mypy src/visionset (152 files).

Not run locally: the pytest suites, the frontend suites, and the two browser suites. The diff is one compose file and one markdown file — no Python, no TypeScript, no generated artifact — so none of them can reach it. Full CI on this PR is the arbiter.

Found, not fixed

Two open Dependabot security alerts, both transitive in pnpm-lock.yaml, neither with a PR:

• nanoid — already satisfied on main; the lockfile carries the patched 3.3.17, so the alert is stale pending a rescan.
• js-yaml 4.3.0 — dev-only, reachable only as openapi-typescript → @redocly/openapi-core → js-yaml. openapi-typescript is already at its latest and pins the older major, so no upstream bump resolves it; a pnpm.overrides entry is the only route. Left out of this PR as unrelated scope.