feat: add SKIP_MIGRATIONS env var to docker entrypoint

Allows skipping the automatic migrate call at startup by setting
SKIP_MIGRATIONS=true. Useful when manually faking migrations before
starting the app, e.g. when rolling back to v0.9 after pruning the
migrations ledger. Default behavior (run migrations) is unchanged.

Updates upgrading.md to document the recovery procedure.

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

Author: marbindrakon

docker-entrypoint.sh

@@ -44,9 +44,14 @@ if [ -n "${SAM_PLUGIN_DIR}" ] || [ -n "${SAM_PLUGIN_PACKAGES}" ]; then
     python manage.py collectstatic --noinput
 fi
 
-# Run database migrations
-echo "Running database migrations..."
-python manage.py migrate --noinput
+# Run database migrations (set SKIP_MIGRATIONS=true to disable, e.g. when
+# manually faking migrations before starting the app after a rollback)
+if [ "${SKIP_MIGRATIONS}" = "true" ]; then
+    echo "Skipping database migrations (SKIP_MIGRATIONS=true)"
+else
+    echo "Running database migrations..."
+    python manage.py migrate --noinput
+fi
 
 # Create superuser if credentials provided and user doesn't exist
 # Django's createsuperuser --noinput reads DJANGO_SUPERUSER_USERNAME,

docs/upgrading.md

@@ -99,6 +99,14 @@ python manage.py migrate health --prune
 `--prune` removes rows that no longer correspond to a migration file on disk.
 It operates on one app at a time, so both apps must be run separately.
 
+> **Note:** Running `--prune` blocks rollback to v0.9. Without the old
+> migration records in `django_migrations`, a v0.9 image will treat migrations
+> `0002` and later as unapplied and attempt to run them against an
+> already-migrated schema, causing startup failures. Only prune if you are
+> confident you will not need to roll back. If you do need to roll back after
+> pruning, start the v0.9 container with `SKIP_MIGRATIONS=true`, exec in, run
+> `python manage.py migrate --fake`, then restart without the flag.
+
 ---
 
 ### Plugin authors