fix(tests): resync serial sequences after baseline restore

TRUNCATE ... RESTART IDENTITY resets every sequence to 1, and the
baseline restore re-inserts seeded rows WITH their explicit ids —
leaving each sequence pointing below MAX(id). Harmless while the only
baseline rows lived in tables tests never sequence-insert into
(ml_settings id=1); migration 0075 seeded tag rows and every Tag insert
after the first truncate collided on pk_tag id=1 (205 failures, run
1888 — find_or_create then surfaced it as NoResultFound via its
conflict-recovery re-select). setval every restored table with a serial
id column past its restored rows.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CDgx8bQS5YrGRK76v8HUnM

tests/conftest.py

@@ -166,6 +166,17 @@ def _reset_db_after_integration(request, _truncate_engine):
             rows = (_SEED_SNAPSHOT or {}).get(t.name)
             if rows:
                 conn.execute(t.insert(), rows)
+                # Restored rows carry their explicit ids while RESTART
+                # IDENTITY reset the sequence to 1, so the next ORM insert
+                # would collide on the PK (bitten by migration 0075's seeded
+                # system tags: every Tag insert failed with pk_tag id=1).
+                # Resync any serial id sequence past the restored rows.
+                if "id" in t.c:
+                    conn.exec_driver_sql(
+                        f"SELECT setval(pg_get_serial_sequence('{t.name}', 'id'), "
+                        f"(SELECT COALESCE(MAX(id), 1) FROM {t.name})) "
+                        f"WHERE pg_get_serial_sequence('{t.name}', 'id') IS NOT NULL"
+                    )
 
 
 @pytest_asyncio.fixture(autouse=True)