docs: warn that pinning back to postgres 16 needs the mount reverted too

Reverting only the image tag leaves 16 running against the 18-style mount, where
PGDATA becomes a subdirectory of the volume rather than its root. 16 then initdbs
a fresh cluster there and Windmill boots against an empty database while the real
one sits unread at the volume root. Verified: the container runs and exits 0, and
a table created before the revert is gone from its view.

Every other path in #10827 fails loudly. This was the exception, and the comment
stopped short of pairing 'staying on 16 is valid' with 'revert the mount too'.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ha6ovKdT9XRoj5FyVe7fEt

docker-compose.yml

@@ -15,6 +15,10 @@ services:
   ## its RLS policies to cluster-level roles, and a single-database dump loses both
   ## silently. Full procedure, and why 16 is still a valid choice until Nov 2028:
   ## https://www.windmill.dev/docs/advanced/self_host#upgrade-postgresql-to-18
+  ## Pinning back to postgres:16 means reverting the mount below as well. 16 against
+  ## the 18-style mount initdbs a fresh cluster into a subdirectory of db_data and
+  ## comes up blank, the one path here that fails quietly instead of loudly. The
+  ## original cluster is still at the volume root, unread, so it is recoverable.
   db:
     deploy:
       # To use an external database, set replicas to 0 and set DATABASE_URL to the external database url in the .env file