fix: revert to one-psql-per-migration to avoid aborted transaction cascade

Batching all migrations into one psql session caused a hard error to put
Postgres into an aborted transaction state, blocking every subsequent
migration. Back to per-file calls with PAGER= still set to prevent hang.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

.gitea/workflows/deploy.yml

@@ -78,16 +78,17 @@ jobs:
           # we need it here for migrations)
           [ -d $APP_DIR/supabase ] || cp -r supabase $APP_DIR/supabase
           cd $APP_DIR
-          # PAGER= prevents psql from launching less/more in a non-interactive shell,
-          # which hangs indefinitely waiting for keypress. Batch all files into one
-          # connection for speed instead of one psql invocation per file.
+          # PAGER= prevents psql launching less/more in a non-interactive shell.
+          # Each migration runs in its own psql call so an error in one file
+          # doesn't abort the transaction and block all subsequent migrations.
           export PAGER=
           export PGPASSWORD="${POSTGRES_PASSWORD}"
           PG="psql -h 127.0.0.1 -U ${POSTGRES_USER} -d ${POSTGRES_DB} --no-psqlrc -v ON_ERROR_STOP=0 -q"
           $PG -f supabase/migrations/000_preflight_supabase_compat.sql || true
           [ -f supabase/captured_schema.sql ] && $PG -f supabase/captured_schema.sql || true
-          # Concatenate all numbered migrations and run in one session
-          cat supabase/migrations/[0-9]*.sql | $PG
+          for f in supabase/migrations/[0-9]*.sql; do
+            $PG -f "$f" || true
+          done
 
       - name: Install dependencies
         run: npm install