fix(migrations): a fresh PostgreSQL database migrates, and CI tests it

The first appsettings migrations insert the default rows with fixed ids,
which a PostgreSQL id sequence does not see; the login lockout migration,
the first to insert without an id, then collided with id 1. It now moves
the sequence past the existing rows first (a no-op on sqlite), which also
covers a database upgraded from any earlier migration. A test compute
password exceeded its 14-character column, which only PostgreSQL enforces.

appsettings/test_migrations.py

@@ -0,0 +1,28 @@
+"""The default settings rows of the first migrations carry fixed ids, which a
+PostgreSQL id sequence does not see. A later migration that inserts without
+an id must not collide with them."""
+
+import importlib
+import unittest
+
+from django.apps import apps
+from django.db import connection
+from django.test import TransactionTestCase
+
+from appsettings.models import AppSettings
+
+login_lockout = importlib.import_module("appsettings.migrations.0014_login_lockout_settings")
+
+
+@unittest.skipUnless(connection.vendor == "postgresql", "id sequences are a PostgreSQL concern")
+class SequenceAfterFixedIdsTestCase(TransactionTestCase):
+    serialized_rollback = True
+
+    def test_login_lockout_settings_insert_after_fixed_ids(self):
+        with connection.schema_editor() as schema_editor:
+            login_lockout.del_settings(apps, schema_editor)
+            # the state after the fixed-id inserts: rows exist, the sequence starts at 1
+            with connection.cursor() as cursor:
+                cursor.execute("SELECT setval(pg_get_serial_sequence('appsettings_appsettings', 'id'), 1, false)")
+            login_lockout.add_settings(apps, schema_editor)
+        self.assertEqual(AppSettings.objects.filter(key__startswith="LOGIN_").count(), 2)