Move the sandbox postgres volume to /var/lib/postgresql and bump the image to 18-alpine

[178inaba]

Why

The E2E job went red on every attempt to move the sandbox PostgreSQL to postgres:18-alpine (#87, Dependabot): the postgres container exited 1 during scripts/redash-up.sh, before Redash was ever started.

The cause was not the seed or the data in the volume — it was where compose.yaml mounted it. From 18 the official image stores the cluster under a major-version directory (/var/lib/postgresql/18/docker) and declares VOLUME /var/lib/postgresql, and its entrypoint refuses to start when it finds a mount at the pre-18 path:

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 reproduces with an empty volume, so a fresh CI runner hits it too (docker-library/postgres#1259). The sandbox is the only thing standing between a Redash-side contract change and a green CI, so the E2E job has to be able to run on a supported PostgreSQL; staying on 17 only defers the same break.

What

compose.yaml's postgres service moves to postgres:18-alpine and mounts its named volume redash-postgres at /var/lib/postgresql. The seed bind mount, the healthcheck, and the pgautoupgrade rationale above the service are untouched, and no PGDATA is set — the parent mount is the layout the image's own entrypoint prescribes for 18+.

The two changes cannot be split, which is why the volume entry carries a comment saying so. Moving the mount first, on 17, was tried and rejected: postgres:17-alpine declares VOLUME /var/lib/postgresql/data, so a named mount on the parent is shadowed by an anonymous volume holding the actual cluster. The server would still start and SHOW data_directory would still answer /var/lib/postgresql/data, but --reset and the README's docker volume rm rdsh-redash-postgres would silently stop removing the database, and every teardown would orphan a volume. Without the comment the path reads like a typo and gets "tidied" back.

Deliberately not changed

• README.md. Its Redash sandbox section already says a PostgreSQL major bump needs --reset, and a 17-era volume remounted under 18 fails loudly with the error above rather than initialising a fresh cluster over it — so the existing remedy needs no rewording.
• pgautoupgrade / in-place pg_upgrade. compose.yaml already records that plain postgres is deliberate because --reset replaces an in-place major upgrade.
• scripts/redash-up.sh, .github/workflows/ci.yml, scripts/redash-seed.sql, e2e/. --reset removes the volume by its fixed name, which does not change; CI starts on an empty volume; the seed produces the same rows under 18.

This supersedes #87. Dependabot normally closes its PR once an equivalent bump lands on main; if it does not, #87 should be closed by hand.

Verification

Run against a machine that already held a 17-era rdsh-redash-postgres volume:

• docker compose --profile redash config — postgres:18-alpine, exactly one named-volume mount, at /var/lib/postgresql.
• scripts/redash-up.sh --reset brought the sandbox up, and docker inspect rdsh-postgres-1 listed the named volume rdsh-redash-postgres and no anonymous volume.
• rdsh run --data-source sandbox "SELECT count(*) FROM signups" returned 40.
• go test -tags e2e -count=1 ./e2e/ passed, as did go test ./... and docker compose run --rm lint.

Closes #88