db: finish reconciling the models with the deployed schema (#3275)

Closes the residue the first reconciliation pass left, and corrects a
factual error I put into the record.

sha256 was NOT missing a uniqueness guarantee. I read
`op.create_index("ix_image_record_sha256", ...)` at 0001 line 151 and
concluded duplicates were possible, without reading line 149 two lines
above it:

    sa.UniqueConstraint("sha256", name="uq_image_record_sha256"),

Uniqueness has held since the initial schema. The database expresses it
as a CONSTRAINT plus a separate non-unique lookup index; the model said
`unique=True, index=True`, which is one UNIQUE index under a different
name. Same guarantee, different objects — which is exactly why the two
schemas did not line up. The model now declares both objects. No DDL.
0088's docstring, which repeated the claim, is corrected in place.

Two real divergences, both the MODEL over-claiming:

  * source: uq_source_artist_platform_url (alembic 0010) was declared
    nowhere in the models — source.py had no __table_args__ at all — so
    autogenerate would have proposed DROPPING it.
  * head_metrics_snapshot.tag_id: model said NOT NULL, 0060 created it
    nullable. Left nullable; the FK already cascades.

Seven constraints renamed to what the chain actually created, rather than
what base.py's naming convention renders: uq_series_page_image,
uq_series_chapter_anchor_page, fk_series_chapter_anchor_page,
fk_image_record_artist_id, fk_image_provenance_from_attachment, and the
two hand-shortened fk_tsr_* names from 0003.

Float server_defaults now mirror their own migration, per column. The
chain is MIXED: a plain string renders DEFAULT '0.90'::double precision,
sa.text() renders DEFAULT 0.90, and the migrations used both. Seven
columns take text(); the rest stay strings. Two literals also disagreed
outright — process_{auto_apply,conflict}_threshold said 0.9/0.5 against
the migration's 0.90/0.50.

baseline.yml gains two things. A repair for a SECOND generator defect in
the same class as the missing pgvector import: base.py's ck convention
contains %(constraint_name)s, so it applies even to a NAMED
CheckConstraint — autogenerate writes the already-rendered name into the
migration and running it applies the convention again, yielding
ck_ml_settings_ck_ml_settings_singleton. That is round-tripping damage,
not a claim the models make, so it is undone rather than counted.

And the diff now runs twice. Column ORDER differs permanently between a
schema built by 87 ADD COLUMNs and one built in a single shot — the
operator's database keeps chain order forever, a fresh install gets model
order — so a check that failed on it could never pass. The second pass
SORTS column lines within each CREATE TABLE instead of deleting them,
which cannot hide a column present on one side only, or one whose type,
nullability or default differs. Ordered diff is reported as information;
the order-insensitive one is the verdict.

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

.forgejo/workflows/baseline.yml

@@ -217,6 +217,42 @@ jobs:
             # comparison is about whether the models describe the schema.
             sed -i '0,/^import sqlalchemy as sa$/s//import sqlalchemy as sa\nimport pgvector.sqlalchemy.vector/' alembic/versions/*.py
             grep -n 'import pgvector' alembic/versions/*.py
+            # Second generator defect, same class as the missing import.
+            #
+            # base.py's naming convention includes %(constraint_name)s for ck,
+            # which — unlike uq/fk/ix — means the convention is applied even to
+            # a CheckConstraint that HAS a name. So a model declaring
+            # name="singleton" correctly becomes ck_ml_settings_singleton in
+            # the metadata. Autogenerate then writes that RENDERED name into
+            # the migration, and running the migration applies the convention a
+            # SECOND time: ck_ml_settings_ck_ml_settings_singleton.
+            #
+            # That is round-tripping damage done by the generator, not a claim
+            # the models make, so it is repaired here rather than counted as a
+            # schema difference. Undone by removing the ck_<table>_ prefix the
+            # convention will re-add — the exact inverse, and it only fires on
+            # a name that actually carries its own table's prefix.
+            python3 - alembic/versions/*.py <<'PYEOF'
+          import re, sys
+
+          table = None
+          for path in sys.argv[1:]:
+              out = []
+              for line in open(path):
+                  m = re.search(r"op\.create_table\(\s*[\"']([A-Za-z0-9_]+)[\"']", line)
+                  if m:
+                      table = m.group(1)
+                  if table and "CheckConstraint" in line:
+                      prefix = f"ck_{table}_"
+                      line = re.sub(
+                          r"(name=[\"'])" + re.escape(prefix),
+                          r"\1",
+                          line,
+                      )
+                  out.append(line)
+              open(path, "w").writelines(out)
+          PYEOF
+            grep -n 'CheckConstraint' alembic/versions/*.py || true
             ls alembic/versions/*.py
             DB_NAME=fc_base alembic upgrade head
             rm -f alembic/versions/*.py
@@ -245,6 +281,25 @@ jobs:
       #   these two lines and nothing else. That control is what licenses this
       #   filter — it was observed to be the only false positive, rather than
       #   assumed to be one.
+      # Column ORDER inside a CREATE TABLE is compared separately from column
+      # CONTENT, and only content is fatal.
+      #
+      # A table built by 87 migrations has its columns in ADD COLUMN order; the
+      # same table built in one shot has them in declaration order. That is a
+      # real and permanent difference which no baseline can erase — the
+      # operator's existing database keeps chain order forever, a fresh install
+      # gets model order — so a check that fails on it would never pass and
+      # would teach nothing. FC reaches every column through the ORM by name,
+      # and `SELECT *` ordering is not depended on anywhere.
+      #
+      # So the second pass SORTS the column lines within each CREATE TABLE
+      # rather than DELETING them. That distinction is the whole point: sorting
+      # cannot hide a column that exists on one side only, or one whose type,
+      # nullability or default differs — those still land in the diff. A filter
+      # could have hidden all three.
+      #
+      # Both diffs are reported. The ordered one is informational; the
+      # order-insensitive one is the verdict.
       - name: Diff
         run: |
           set -eu
@@ -256,11 +311,54 @@ jobs:
           norm chain.sql > a.txt
           norm baseline.sql > b.txt
           echo "normalised: chain=$(wc -l < a.txt) lines, current=$(wc -l < b.txt) lines"
+
+          sort_table_columns() {
+            python3 - "$1" <<'PYEOF'
+          import re, sys
+
+          lines = open(sys.argv[1]).read().splitlines()
+          out, block = [], None
+          for line in lines:
+              if block is not None:
+                  # ');' on its own closes the CREATE TABLE body.
+                  if line.strip() == ");":
+                      out.extend(sorted(block))
+                      out.append(line)
+                      block = None
+                  else:
+                      # Drop the list comma before sorting. Only the LAST
+                      # column lacks one, so keeping it would make every
+                      # reordering look like a content change as well — the
+                      # comma is punctuation, and carries no schema meaning.
+                      block.append(line.rstrip().rstrip(","))
+                  continue
+              out.append(line)
+              if re.match(r"CREATE TABLE .*\($", line):
+                  block = []
+          if block is not None:  # unterminated body: emit it rather than drop it
+              out.extend(block)
+          print("\n".join(out))
+          PYEOF
+          }
+          sort_table_columns a.txt > a.sorted.txt
+          sort_table_columns b.txt > b.sorted.txt
+          test "$(wc -l < a.sorted.txt)" = "$(wc -l < a.txt)"
+          test "$(wc -l < b.sorted.txt)" = "$(wc -l < b.txt)"
+
           if diff -u a.txt b.txt > schema.diff; then
-            echo "SCHEMAS IDENTICAL — the collapsed chain reproduces the old one."
+            echo "ORDERED DIFF: identical, column order included."
           else
-            echo "SCHEMAS DIFFER — $(grep -cE '^[+-]' schema.diff) changed lines:"
+            echo "ORDERED DIFF: $(grep -cE '^[+-]' schema.diff) changed lines (informational):"
             cat schema.diff
+          fi
+          echo
+          echo "================================================================"
+          echo
+          if diff -u a.sorted.txt b.sorted.txt > sorted.diff; then
+            echo "SCHEMAS MATCH — every difference above is column ORDER alone."
+          else
+            echo "SCHEMAS DIFFER — $(grep -cE '^[+-]' sorted.diff) changed lines that are NOT ordering:"
+            cat sorted.diff
             echo
             echo "The baseline is wrong, not the database. Do not stamp."
             exit 1