chore(docker): track current Postgres and Supabase bases, add PostgreSQL 18

[andinux]

Stacked on #62 so both land as a single 1.1.3 release. Merging #62 on its own would cut 1.1.3 immediately and publish :17 on the frozen 17.6.1.071 and :15 on 15.8.1.135 — the exact bases this PR retires.

Closes #59.

Why

docker-publish only runs on main when the release job cuts a release, so it was skipped for #58 and #61. Docker Hub confirms it: :15 still resolves to base 15.8.1.085 and 15.8.1.135 was never published. Meanwhile upstream moved on.

	was	now
Supabase PG17	17.6.1.071 (Ubuntu, frozen)	17.6.1.170 (Alpine)
Supabase PG15	15.8.1.135 queued (Ubuntu)	15.14.1.170 (Alpine)
Official postgres	17, 15	18, 17, 15

The PG15 move also advances PostgreSQL 15.8 → 15.14.

On #59

#59 planned a two-release migration — publish :17-ubuntu, announce deprecation, then flip :17 — to protect existing :17 pins. There are no production deployments to protect, so that sequence is pure cost and the alias moves in one step.

Its "naming rule to settle first" is also moot: it assumed PG15 stays on Ubuntu, so a -ubuntu/-alpine split would be non-uniform across majors. Supabase has since moved PG15 to Alpine too (verified by inspecting the image configs: 15.14.1.169/15.14.1.170 are Alpine, 15.8.1.x are Ubuntu). Both majors are now one family, so the durable rule is simply :<major> tracks whatever base Supabase currently ships, with no family suffixes. :17-alpine is retired because :17 is now the same image, and the tag_suffix mechanism is removed with it — which also drops the need for the extra_tags workflow extension #59 predicted.

PostgreSQL 18

Added to postgres-test, postgres-build (4 arch/OS rows) and docker-publish, producing cloudsync-postgresql18-* artifacts and sqlitecloud/sqlite-sync-postgres:18. There are no PG_VERSION_NUM guards in src/postgresql/, so 18 compatibility was the open question — it builds and passes clean. Homebrew has postgresql@18 and PGDG has postgresql-server-dev-18 for jammy on both arches, so every CI row resolves. PG19 is still beta3; skipped.

PG18 stores data in a major-version subdirectory (/var/lib/postgresql/18/docker) and refuses to start when a volume is mounted at the old /var/lib/postgresql/data, even on a clean volume. The compose files and the quickstart now mount the parent /var/lib/postgresql, which works on 15 and 17 as well.

Also

• .github/workflows/changelog.yml listened for v*.*.* tags, but main.yml creates tags without the prefix (1.1.2). It has never fired automatically on a release.
• Folded the orphaned [Unreleased] entries into [1.1.3] and rewrote the :15 entry, whose Ubuntu-24.04 uid numbers no longer describe the move.
• docker/README.md claimed the dev container runs PostgreSQL 16, and that the build-from-source flow assumes an Ubuntu base (fixed by fix: make local Supabase build-from-source work on Alpine bases #61).

Verification

All local, on this branch:

• Full suite 477/477, 0 failures on PG18, PG17 and PG15 with the new mount
• CloudSync builds from source and CREATE EXTENSION succeeds on both new Supabase bases — cloudsync_version() = 1.1.3 on PostgreSQL 15.14 and 17.6, postgres uid 100:101 on each
• make postgres-check-migration passes (patch-only, no migration script required)
• Workflow YAML re-parsed after editing

Not covered: the new PG15 Alpine base inside a full self-hosted Supabase stack. Alpine 17 was validated that way on Fly.io (#59); PG15 has only had the CREATE EXTENSION smoke test that CI runs.

🤖 Generated with Claude Code

https://claude.ai/code/session_01CCE6B54Qtf3UsaCVAJtVQF