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>

tests/Console/CoreCommandsTest.php

@@ -0,0 +1,99 @@
+<?php
+
+namespace MintyPHP\Tests\Console;
+
+use MintyPHP\Console\Commands\Database\MigrateCommand;
+use PHPUnit\Framework\TestCase;
+
+final class CoreCommandsTest extends TestCase
+{
+    public function testDbMigrateSuccessOutputAndExitCode(): void
+    {
+        $runner = new FakeModuleRunner();
+        $runner->dbMigrateResult = [
+            'command' => 'db:migrate',
+            'status' => 'ok',
+            'exit_code' => 0,
+            'vendor_warnings_ignored' => 0,
+            'message' => 'db-migrate: applied 3 migration(s).',
+        ];
+
+        $command = new MigrateCommand($runner);
+
+        ob_start();
+        $exitCode = $command->execute([], []);
+        $output = (string) ob_get_clean();
+
+        self::assertSame(0, $exitCode);
+        self::assertStringContainsString('db-migrate: applied 3 migration(s).', $output);
+    }
+
+    public function testDbMigrateFailureWritesToStderrAndReturnsNonZero(): void
+    {
+        $runner = new FakeModuleRunner();
+        $runner->dbMigrateResult = [
+            'command' => 'db:migrate',
+            'status' => 'failed',
+            'exit_code' => 1,
+            'vendor_warnings_ignored' => 0,
+            'message' => 'db-migrate: failure: Core migration foo.sql failed: SQLSTATE[42S02]',
+        ];
+
+        $command = new MigrateCommand($runner);
+
+        ob_start();
+        $exitCode = $command->execute([], []);
+        ob_end_clean();
+
+        self::assertSame(1, $exitCode);
+    }
+
+    public function testDbMigrateStatusListsAppliedAndPending(): void
+    {
+        $runner = new FakeModuleRunner();
+        $runner->dbMigrateStatusResult = [
+            'command' => 'db:migrate --status',
+            'applied' => [
+                '2026-02-23-tenant-scope-global.sql',
+                '2026-03-13-seed-default-roles.sql',
+            ],
+            'pending' => [
+                '2026-04-29-core-migrations-table.sql',
+            ],
+        ];
+
+        $command = new MigrateCommand($runner);
+
+        ob_start();
+        $exitCode = $command->execute([], ['status' => true]);
+        $output = (string) ob_get_clean();
+
+        self::assertSame(0, $exitCode);
+        self::assertStringContainsString('2 applied, 1 pending', $output);
+        self::assertStringContainsString('2026-02-23-tenant-scope-global.sql', $output);
+        self::assertStringContainsString('2026-04-29-core-migrations-table.sql', $output);
+        self::assertStringContainsString("applied:\n", $output);
+        self::assertStringContainsString("pending:\n", $output);
+    }
+
+    public function testDbMigrateStatusHandlesEmptyLists(): void
+    {
+        $runner = new FakeModuleRunner();
+        $runner->dbMigrateStatusResult = [
+            'command' => 'db:migrate --status',
+            'applied' => [],
+            'pending' => [],
+        ];
+
+        $command = new MigrateCommand($runner);
+
+        ob_start();
+        $exitCode = $command->execute([], ['status' => true]);
+        $output = (string) ob_get_clean();
+
+        self::assertSame(0, $exitCode);
+        self::assertStringContainsString('0 applied, 0 pending', $output);
+        self::assertStringContainsString("applied:\n  (none)", $output);
+        self::assertStringContainsString("pending:\n  (none)", $output);
+    }
+}