Rewrite migrations to Doctrine Schema tool + PHPStan enforcement

[turegjorup]

Note

Stacked on #441 (now merged). Targets release/3.0.0.

Why now

A major version is the natural cut-point for changing migration conventions, and the consolidated 3.0 migration is the entire current migration population — so it's also a one-time chance to rewrite everything in one place.

Concretely, migrations now go through Doctrine's Schema tool API ($schema->createTable(), $table->addColumn(), $table->addForeignKeyConstraint(), …) instead of raw addSql(...) strings. The emitted DDL is identical for MariaDB but the migration is now generated through the platform abstraction, so the same code produces native DDL on any database Doctrine supports.

This PR lays the groundwork for portability — it does not claim it. Runtime is still MariaDB-only and native SQL in entity listeners is deferred. CI now exercises Postgres as a schema-portability regression gate only (see below); it does not validate that the application runs on Postgres.

Summary

• Rewrites Version20260506215847.php from 154 raw addSql calls to the equivalent Schema tool builders. A small applyTableOptions() helper at the bottom collapses the engine/charset/collation triplet that would otherwise repeat 29 times.
• Replaces every type-name string literal ('string', 'datetime_immutable', …) with the corresponding Doctrine\DBAL\Types\Types::* constant — plus UlidType::NAME and RRuleType::RRULE for the two custom types — so renames propagate via the type system rather than across free-form strings.
• Adds App\PhpStan\NoAddSqlInMigrationRule, a project-local PHPStan rule that flags any $this->addSql(...) call inside migrations/. PHPStan path coverage extended to migrations/.
• Wires the rule via tools/phpstan/ + composer autoload-dev so it's available at lint time but never loaded into the runtime container.
• Picks up Consolidate 25 historical 2.x migrations into one end-of-2.8 schema #441/feat: prep db identifiers for cross-platform (Postgres) portability #444 into the resolved migration: 15 <table>_changed_idx index names and the backtick-quoted user table, applied to the Schema-tool body without re-introducing raw SQL.
• Adds a Postgres schema-portability CI gate (Validate Schema (postgres:16, experimental) in .github/workflows/doctrine.yaml) that runs the consolidated migration against Postgres 16 and validates the resulting schema. The new docker-compose.postgres.yml override declares the postgres service and layers pdo_pgsql onto phpfpm via dockerfile_inline, so the same setup works locally.
• ADR 010 documents the convention (Schema tool API, no addSql for DDL) and the rule going forward: future schema changes must keep the Postgres gate green.
• CHANGELOG entries under [Unreleased].

On Rector

No off-the-shelf Rector rule covers either conversion: Rector\Transform\Rector\Attribute\AttributeKeyToClassConstFetchRector handles #[Column(type: 'string')] on entity attributes but not method-call arguments, and there's no rule for addSql → Schema tool. The string-to-constant conversion in this PR was scripted with a small Python regex pass and verified by re-running migrate + schema:validate. A custom Rector rule was considered overkill for a single migration; the PHPStan rule prevents the worse problem (raw addSql) on future migrations.

Test plan

• Fresh install end-to-end on MariaDB 11.4: drop test DB → create → migrations:migrate → schema:validate exits 0
• 2.x → 3.0 upgrade simulation: applied 25 latest-2.8.x migrations to fresh DB → swap files → migrations:rollup → schema:validate exits 0
• Postgres 16 portability gate: migrations:migrate applies the consolidated Schema-tool migration cleanly (264 queries) → schema:validate in sync, no MariaDB-specific DDL leaked
• mysqldump --no-data diff vs the previous raw-SQL version on MariaDB: only column reordering and index reordering (Schema tool emits columns in addColumn() insertion order). No functional differences. The single FK name divergence on interactive_slide_config (FK_138E544D9033212A vs FK_D30060259033212A) is a pre-existing artifact from the table rename that was already present in Consolidate 25 historical 2.x migrations into one end-of-2.8 schema #441 and didn't break CI there.
• Full PHPUnit suite: 155 tests / 637 assertions green (post-release/3.0.0 sync brought in 6 new InstantBook tests)
• PHPStan green; rule verified to fire on a smoke-test migration with addSql('SELECT 1') (then deleted)
• CI green on this PR (incl. the new Postgres job)

Out of scope (deferred)

• Native SQL in entity listeners (MultiTenantRepositoryTrait, RelationsChecksumCalculator) — same conversion needs doing there too, but this PR is scoped to migrations.
• Running PHPUnit / fixtures / runtime queries against Postgres — the CI gate is schema-level only.
• Switching the deployment target away from MariaDB.

🤖 Generated with Claude Code