Support PostgreSQL 18+ properly, guard existing data against version bumps

[jannefleischer]

Closes the gap left by pinning POSTGRES_VERSION to 16 as a workaround (github.com/#35): postgres 18 needs the volume mounted a level up, at /var/lib/postgresql (it manages its own version-named subdirectory there), instead of directly at .../data.

• Add POSTGRES_DATA_MOUNT (default: /var/lib/postgresql/data, i.e. unchanged behavior for every existing deployment) to control the postgres volume's container-side mount target. Set it to /var/lib/postgresql alongside POSTGRES_VERSION=18 (or newer) to use the new layout. Verified both a default (16) fresh deploy and an 18 fresh deploy end to end.
• fixperms (docker/fixperms/fixperms.sh) now also compares the PostgreSQL major version already on disk against POSTGRES_VERSION before touching anything. Major-version upgrades need pg_dump/pg_restore (or pg_upgrade with both binaries present) - a bind-mount layout change alone doesn't convert the on-disk format, and 18 can't read a 16 data directory. On a mismatch, fixperms backs up vol/postgres to a timestamped .tar.gz and exits non-zero, which blocks postgres/rdmo/caddy from starting at all (verified: they stay in "Created", never start). This turns "silently read the wrong data or quietly initialize a second, empty database" into "stop cold, with a backup and an explanation".
• Documented the manual pg_dump/pg_restore upgrade path in readme.md.

Verified against the real, already-running deployment (POSTGRES_VERSION=15 in its .env): fixperms correctly reports a version match and changes nothing.