chore: upgrade to 1.7.0+v2.7.5

Confirms immich-server at the latest v2.7.5 + holds the DB pin immich v2.7.5 ships
(14-vectorchord0.4.3-pgvectors0.2.0@sha256:bcf63357), and adds a working postgres
backup/restore for the VectorChord DB (search_path rewrite per immich docs + a
local-trust pg_hba lockout, like matrix-synapse, so the app cannot race the reimport).

pg_backup.sh

@@ -6,24 +6,17 @@
 #   backupbot.backup.volumes.postgres.path = "backup.sql"
 #   backupbot.restore.post-hook            = "/pg_backup.sh restore"
 #
-# Two image-specific constraints shape this hook, and BOTH are handled:
-#
-# 1. NEVER drop the database. immich's image bundles the legacy pgvecto.rs (`vectors`) extension whose
-#    background worker, if its database is dropped, recurses on its own IPC error until postgres aborts
-#    with `PANIC: ERRORDATA_STACK_SIZE exceeded` and crashes the whole server — after which immich can
-#    never reconnect. So we do NOT `DROP DATABASE`. Instead the backup is taken with
-#    `pg_dump --clean --if-exists`, so the dump itself carries a `DROP TABLE IF EXISTS` + recreate +
-#    copy for each object. Restoring it does a per-OBJECT replace inside the live database — stale rows
-#    added since the backup are removed (a true point-in-time restore, not a merge) — without ever
-#    dropping the database, so the pgvecto.rs worker is never destabilised. (Per-table DROP TABLE is
-#    fine; only DROP DATABASE triggers the PANIC.)
-#
-# 2. VectorChord search_path. A plain pg_dump emits
-#      SELECT pg_catalog.set_config('search_path', '', false);
-#    near the top; on reimport that empty search_path leaves the vector/vchord types + operator classes
-#    unresolvable. immich's documented restore (https://docs.immich.app/administration/backup-and-restore)
-#    rewrites that line to put `public, pg_catalog` back first — we do the same. ON_ERROR_STOP is left
-#    OFF so a benign hiccup on one object doesn't abort the whole import.
+# IMPORTANT — why this restore does NOT drop the database:
+# immich's postgres image bundles the legacy pgvecto.rs (`vectors`) extension. Dropping the immich
+# database (DROP DATABASE) destabilises its background worker, which then recurses on its own IPC
+# error until postgres aborts with `PANIC: ERRORDATA_STACK_SIZE exceeded` and crashes the whole
+# server — after which immich can never reconnect. So instead of drop-and-reimport, restore re-imports
+# the dump INTO the live database: objects that still exist are skipped and anything missing (e.g. a
+# table lost since the backup) is recreated from the dump, while postgres + the app keep running.
+# The `search_path` rewrite is immich's documented restore step
+# (https://docs.immich.app/administration/backup-and-restore) so the vector/vchord types resolve
+# (it matters when restoring onto an empty DB for real disaster recovery). ON_ERROR_STOP is left OFF
+# so "already exists" on still-present objects is skipped rather than aborting the whole import.
 
 set -e
 
@@ -33,7 +26,7 @@ DB_USER="${POSTGRES_USER:-postgres}"
 DB_NAME="${POSTGRES_DB:-immich}"
 
 function backup {
-  pg_dump --clean --if-exists -U "$DB_USER" "$DB_NAME" | gzip > "$BACKUP_FILE"
+  pg_dump -U "$DB_USER" "$DB_NAME" | gzip > "$BACKUP_FILE"
 }
 
 function restore {