fix: Upgrade postgres 14 -> 17

[spalmurray]

Oops missed this one in the last pr.

[seer-by-sentry]

Bug: Upgrading PostgreSQL from version 14 to 17 without a data migration path will break existing self-hosted deployments with persistent data.
_{(Severity: Critical 0.85 | Confidence: 0.98)}

🔍 Detailed Analysis

The postgres service image is upgraded from postgres:14-alpine to postgres:17-alpine, which is a major version upgrade. For existing self-hosted deployments that use the persistent postgres-volume, the new PostgreSQL 17 container will attempt to read data files created by PostgreSQL 14. Due to binary incompatibility between major PostgreSQL versions, this will cause the container to fail on startup, making the service unavailable. The change lacks the necessary data migration scripts (e.g., using pg_upgrade or pg_dump) or documentation to guide users through the upgrade process.

💡 Suggested Fix

Provide a data migration strategy for users with existing data. This could involve documenting a manual pg_dump/pg_restore process, providing a migration script, or using a tool like pgautoupgrade. At a minimum, clearly document this as a breaking change and advise users on how to handle their existing data.

🤖 Prompt for AI Agent

Fix this bug. In docker-compose.yml at line 77: The `postgres` service image is upgraded
from `postgres:14-alpine` to `postgres:17-alpine`, which is a major version upgrade. For
existing self-hosted deployments that use the persistent `postgres-volume`, the new
PostgreSQL 17 container will attempt to read data files created by PostgreSQL 14. Due to
binary incompatibility between major PostgreSQL versions, this will cause the container
to fail on startup, making the service unavailable. The change lacks the necessary data
migration scripts (e.g., using `pg_upgrade` or `pg_dump`) or documentation to guide
users through the upgrade process.

_{Did we get this right? 👍 / 👎 to inform future reviews.}