feat(console): add db:migrate CLI for idempotent core schema updates

Existing systems used to have no automatic mechanism for the
db/updates/*.sql idempotent updates after `git pull` — devs had to
remember which files were already applied and run new ones manually
with `mariadb < ...`. Mirror module:migrate to fix this:

- New `bin/console db:migrate` walks db/updates/*.sql in alphabetical
  order, skipping anything already recorded in the new core_migrations
  tracking table. Each file runs in its own transaction; failure
  rolls back so the file is retried on the next run.
- New `db:migrate --status` lists applied vs. pending files without
  running anything. Useful for ops debugging "schema seems stale"
  symptoms.
- module:sync now runs db:migrate as its first step, so the standard
  post-pull command stays a single invocation. README's 3-step setup
  is unchanged — module:sync now also covers core schema updates.

CoreMigrationRepository owns its own mysqli connection (using the
same DB credentials as MintyPHP\DB) and runs raw `$mysqli->query()`
instead of going through DB::query's prepared statement path —
MariaDB rejects some DDL (e.g. ALTER TABLE … ADD CONSTRAINT CHECK)
in the prepared protocol, which the existing 18 db/updates files
trip on. ModuleMigrationRepository is left untouched (no module
migration uses such DDL today and changing the vendor pattern is
out of scope).

End-to-end verified: against an existing DB the first run applies
all 19 idempotent files as no-ops and records them, second run
reports "all updates already applied". Against a freshly init'd
DB the same thing happens — no double work, no surprises. All
encrypted seed secrets keep decrypting because APP_CRYPTO_KEY
is unchanged.

Tests: tests/Console/CoreCommandsTest covers success/failure/status
output shapes against a FakeModuleRunner (mirror of the existing
ModuleCommandsTest pattern). 5 stale baseline entries in
phpstan-baseline removed (covered by the new @api annotation on
the test fixture class).

Docs: CLAUDE.md and docs/reference-cli-commands.md document the
new command + --status flag; docs/howto-fehlerbehebung.md gains
a "schema seems stale after git pull" section pointing at
db:migrate --status.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

docs/howto-erste-aenderung.md

@@ -38,7 +38,7 @@ Ein neuer Entwickler soll den ersten Change strukturiert und reproduzierbar umse
 3. Optional Service/Repository ergänzen, Instanziierung über `app(...)`/Factory-Standards
 4. `docs/openapi.yaml` aktualisieren
 5. `/docs/reference-api.md` mit Beispiel aktualisieren
-6. Bei neuen Berechtigungen: `PermissionService` + `init.sql` synchron halten, für Bestandsumgebungen idempotentes SQL-Update in `db/updates/*.sql` bereitstellen
+6. Bei neuen Berechtigungen: `PermissionService` + `init.sql` synchron halten, für Bestandsumgebungen idempotentes SQL-Update in `db/updates/*.sql` bereitstellen — wird automatisch von `bin/console db:migrate` (bzw. `module:sync`) angewendet
 
 ### Done-Kriterien
 

docs/howto-fehlerbehebung.md

@@ -1,6 +1,21 @@
 # Fehlerbehebung
 
-Letzte Aktualisierung: 2026-03-14
+Letzte Aktualisierung: 2026-04-29
+
+## Schema scheint veraltet nach `git pull`
+
+### Symptom
+
+Nach einem Pull schlagen Queries fehl, weil eine Spalte/Tabelle fehlt — oder der Doctor meldet inkonsistentes Schema.
+
+### Lösung
+
+```bash
+docker compose exec php php bin/console db:migrate --status   # zeigt was fehlt
+docker compose exec php php bin/console module:sync           # wendet alles an (db:migrate + module:migrate + ...)
+```
+
+`db:migrate` wendet idempotente Updates aus `db/updates/*.sql` an und trackt sie in `core_migrations`. Auch nach manuellem `mariadb < db/updates/...sql` sicher: jeder Lauf ist idempotent.
 
 ## App reagiert nicht wie erwartet
 

docs/reference-cli-commands.md

@@ -26,13 +26,13 @@ php bin/console <command> --help
 
 ### module:sync
 
-Fuehrt den vollstaendigen Modul-Runtime-Sync aus: `migrate` → `permissions-sync` → `build` → `assets-sync`.
+Fuehrt den vollstaendigen Runtime-Sync aus: `db-migrate` → `migrate` → `permissions-sync` → `build` → `assets-sync`.
 
 ```bash
 docker compose exec php php bin/console module:sync
 ```
 
-Noetig nach jeder Aenderung an Modulen, Manifesten, Routen oder `APP_ENABLED_MODULES`.
+Noetig nach jeder Aenderung an Modulen, Manifesten, Routen oder `APP_ENABLED_MODULES` — und nach jedem `git pull`, der Schema-Updates unter `db/updates/*.sql` mitbringt.
 
 Falls `web/index.php` den Fehler "Module runtime is stale" wirft, ist dieser Befehl die Loesung.
 
@@ -42,6 +42,26 @@ Maschinenlesbar:
 docker compose exec php php bin/console module:sync --format=json
 ```
 
+### db:migrate
+
+Wendet idempotente Core-Schema-Updates aus `db/updates/*.sql` an. Angewendete Files werden in der Tabelle `core_migrations` getrackt; jeder Lauf wendet nur neu hinzugekommene Files an.
+
+Jede `db/updates/*.sql` MUSS idempotent sein (`CREATE TABLE IF NOT EXISTS`, `INSERT … ON DUPLICATE KEY UPDATE`, etc.) — Erstlauf gegen ein bereits bestehendes Schema ist damit ein No-op.
+
+```bash
+docker compose exec php php bin/console db:migrate
+```
+
+`module:sync` ruft den Befehl als ersten Schritt automatisch auf. Direktaufruf nuetzlich, wenn nur DB-Updates gewuenscht sind ohne Module-Build.
+
+Status-Anzeige (kein Schreibzugriff):
+
+```bash
+docker compose exec php php bin/console db:migrate --status
+```
+
+Listet `applied:` und `pending:` separat — nuetzlich beim Debugging veralteter Schemata.
+
 ### module:migrate
 
 Wendet ausstehende SQL-Migrationen aus aktiven Modulen an.