CI: Schema vor den Tests anlegen

Der vorige Commit setzte SYNCOVA_TEST_DATABASE_URL, damit die Datenbanktests in
der CI nicht mehr still uebersprungen werden. Das haette die CI rot gemacht: Die
Tests laufen dort **vor** dem Migrationsschritt, die Datenbank ist zu dem
Zeitpunkt leer, und neun Testdateien scheitern an einem fehlenden Schema.

Aufgefallen ist es beim Nachbau der CI-Umgebung in einem Container — nicht in
der CI selbst, weil die Actions-API dieser Gitea-Fassung nicht erreichbar ist.

Jetzt:

- "Schema vor den Tests anlegen" laeuft als eigener Schritt vor den Tests.
- Der Migrationszyklus (down/up) bleibt danach. Zwischen down und up fehlt eine
  Migration; ein Test in genau diesem Moment scheiterte an einem Schemastand,
  den es im Betrieb nie gibt.

Die Verbindungszeichenkette des CI-Containers traegt secretscan:erlaubt — in
derselben Zeile, nicht darueber, sonst greift der Vermerk nicht.

Nachgewiesen gegen eine frische PostgreSQL 17 in der exakten Reihenfolge der
CI: gofmt, go vet, Schema, Tests mit Race-Detector, Migrationszyklus,
cross-build — alle sechs Schritte bestanden.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

.github/workflows/ci.yml

@@ -73,6 +73,22 @@ jobs:
           # Eine Änderung an go.mod/go.sum bedeutet: die Abhängigkeiten sind nicht eingecheckt.
           git diff --exit-code go.mod go.sum
 
+      - name: Schema vor den Tests anlegen
+        env:
+          SYNCOVA_ENV: test
+          SYNCOVA_DB_HOST: 127.0.0.1
+          SYNCOVA_DB_PORT: '5432'
+          SYNCOVA_DB_NAME: syncova_test
+          SYNCOVA_DB_USER: syncova_test
+          SYNCOVA_DB_PASSWORD: ci-only-ephemeral-password
+          SYNCOVA_DB_SSLMODE: disable
+          # Nur für diesen CI-Lauf; schützt keine echten Daten.
+          SYNCOVA_ENCRYPTION_KEYS: 'v1:AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA='
+        # Muss vor den Tests laufen. Die Datenbanktests erwarten ein Schema; auf
+        # einer leeren Datenbank scheitern sie. Solange SYNCOVA_TEST_DATABASE_URL
+        # fehlte, uebersprangen sie und der Fehler blieb verborgen.
+        run: go run ./apps/api/cmd/syncova-migrate up
+
       - name: Tests mit Race-Detector
         env:
           SYNCOVA_ENV: test
@@ -87,7 +103,7 @@ jobs:
           # Ohne diese Variable überspringen neun Testdateien ihre Datenbanktests
           # still — darunter der Upgrade- und der Rollback-Test. Ein übersprungener
           # Test sieht in der Zusammenfassung aus wie ein bestandener.
-          SYNCOVA_TEST_DATABASE_URL: 'postgres://syncova_test:ci-only-ephemeral-password@127.0.0.1:5432/syncova_test?sslmode=disable'
+          SYNCOVA_TEST_DATABASE_URL: 'postgres://syncova_test:ci-only-ephemeral-password@127.0.0.1:5432/syncova_test?sslmode=disable' # secretscan:erlaubt: kurzlebiger CI-Container, von aussen nicht erreichbar
         run: go test -race -coverprofile=coverage.out $(go list ./... | grep -v '/node_modules/')
 
       - name: Migrationen gegen echte Datenbank prüfen
@@ -103,7 +119,9 @@ jobs:
           SYNCOVA_ENCRYPTION_KEYS: 'v1:AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA='
         run: |
           # Der vollständige Zyklus belegt, dass Migrationen umkehrbar sind.
-          go run ./apps/api/cmd/syncova-migrate up
+          # Er läuft nach den Tests: Zwischen 'down' und 'up' fehlt eine
+          # Migration, und ein Test in diesem Moment scheiterte an einem
+          # Schemastand, den es im Betrieb nie gibt.
           go run ./apps/api/cmd/syncova-migrate status
           go run ./apps/api/cmd/syncova-migrate down
           go run ./apps/api/cmd/syncova-migrate up