chore: scaffold and verify on PostgreSQL 18

[Bccorb]

Follow-up to the version audit on #146, where I flagged postgres:17 as a major behind and said it wanted its own PR.

The drift

Two pins had come apart:

Where	Was	Now
src/core/images.ts (what init scaffolds)	postgres:17	postgres:18
verify/docker-compose.verify.yml (the harness)	postgres:16	postgres:18

The harness was certifying a different major than a fresh scaffold actually got, which is the part worth fixing regardless of which version wins.

Blast radius, corrected

I was more alarmist about this on #146 than it deserved. I said it "breaks the data directory for anyone with an existing volume" — that is wrong for this repo, and I checked before writing the bump:

• POSTGRES_IMAGE is interpolated into each scaffold's own docker-compose.yml at generation time (src/generators/docker/docker.ts). An existing project keeps the major it was scaffolded with; nothing reaches back and changes it.
• The harness runs compose down -v at the start of every run, so its volume is always fresh.

So this reaches new scaffolds on a new volume, and nothing else. Upgrading an existing project stays a deliberate act (change the image, dump and restore), and the changeset says so.

Checks

npm run build and npm test pass (815 passed, 4 skipped). Scaffolded a project from the built CLI and confirmed its generated compose says image: postgres:18. Smoke-tested the image itself: PostgreSQL 18.4 (Debian 18.4-1.pgdg13+1) starts and answers queries.

The verify / verify CI job is the real test here, since it stands the whole stack up on 18. I did not run it locally this time because the ports were in use.

Not in this PR

The org has other postgres pins, inventoried in a comment below. They are separate repos with separate risk (several have long-lived local dev volumes, and the Aurora pins are production), so they want their own PRs rather than being swept in here.

[Bccorb]

Org-wide postgres inventory

Searched the org rather than guessing. Three tiers, and only the first is low-risk like this PR:

Tier 1 — generated or ephemeral (safe, same reasoning as this PR)

Repo	File	Pin
seamless-templates	templates/api/express/docker-compose.yml	postgres:16
seamless-templates	templates/api/fastify/docker-compose.yml	postgres:16
seamless-review-api	.github/workflows/ci.yml	postgres:15
seamless-review-api	test/setup.ts	postgres:16

Template compose files are copied into new projects, so bumping them only affects future scaffolds. CI and test-harness containers are per-run. These are two majors behind and, notably, the templates are what seamless-cli scaffolds alongside the compose file this PR just moved to 18, so they should match.

Tier 2 — long-lived local dev volumes (needs a note, not just a bump)

Repo	File	Pin
seamless-auth-api	docker-compose.yml, docker-compose.dev.yml	postgres:16
seamless-portal-api	docker-compose.yml	postgres:17
seamless-review-api	docker-compose.yml	postgres:16
grand-cross-api	docker-compose.yml	postgres:17

These are checked-out repos where developers have a running volume. Bumping the major means the container refuses to start against the existing data directory: database files are incompatible with server. Each needs a dump/restore step in its README or a one-time docker compose down -v blessed in the PR. Worth doing them one at a time so a broken local stack is attributable.

Tier 3 — production, do not sweep

Repo	File
seamless-iac	serverless-{trial,paid}-shared/modules/aurora/*.tf
seamless-terraform-service	paid-jobs/aurora.tf, dev.tfvars

Aurora PostgreSQL, with the concrete engine_version supplied per environment via tfvars rather than committed. Two things to settle before touching these: whether Aurora Serverless v2 offers a PostgreSQL 18 compatible version at all (its majors lag community Postgres), and that a managed major-version upgrade is an availability event on real customer data. This is a planned maintenance task, not a version bump.

Docs referencing versions in passing (seamless-iac/docs/adr/0003-*, docs/module-catalog.md) should follow whatever tier 3 settles on.

Happy to take tier 1 next, since it is the same argument as this PR and closes the gap between the CLI and the templates it scaffolds.

[Bccorb]

Rollout logged

Filed a tracking issue in every repo with a postgres pin that is not 18. Verified each pin by
fetching the file rather than trusting code search, which corrected the inventory above: several are
-alpine variants, so the fix needs to preserve that.

Repo	Issue	Files	Current
seamless-templates	fells-code/seamless-templates#41	both API starters' docker-compose.yml	postgres:16-alpine
seamless-auth-api	fells-code/seamless-auth-api#143	docker-compose.yml, docker-compose.dev.yml	postgres:16
seamless-review-api	fells-code/seamless-review-api#13	ci.yml, test/setup.ts, docker-compose.yml	postgres:15, 16, 16-alpine
seamless-portal-api	fells-code/seamless-portal-api#105	docker-compose.yml	postgres:17-alpine
grand-cross-api	fells-code/grand-cross-api#12	docker-compose.yml	postgres:17

Each issue states its own risk rather than repeating a generic bump. The compose files that back a
live volume carry the database files are incompatible with server failure and a dump/restore path;
the CI and test-harness containers are noted as free.

seamless-templates is the one worth doing first: a project from seamless init now names
postgres:18 in the CLI-generated compose file and postgres:16-alpine in the starter copied in
beside it. That inconsistency is one this PR introduced.

Not filed: the Aurora pins in seamless-iac and seamless-terraform-service. They are neither a
docker compose file nor a pg image, the concrete engine_version comes from per-environment tfvars,
and a managed major upgrade on customer data is planned maintenance rather than a version bump.
Someone should confirm Aurora Serverless v2 even offers a PostgreSQL 18 compatible version before
that gets a ticket.