WIP: rewrite migrations to Doctrine Schema tool + PHPStan enforcement

[turegjorup]

Note

Stacked on #441. Targets feature/consolidate-migrations; retarget to release/3.0.0 after #441 merges.

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, native SQL in entity listeners is deferred, and CI does not yet exercise other platforms. The conversion is scoped to migrations because we're already touching them in #441 (consolidation + rollup), so the cost of doing it now is low and the convention is set going forward.

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.
• CHANGELOG entry 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: drop test DB → create → migrations:migrate → schema:validate exits 0
• 2.x → 3.0 upgrade simulation: applied 25 latest-2.7.x migrations to fresh DB → swap files → migrations:rollup → schema:validate exits 0
• 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 WIP: consolidate 25 historical 2.x migrations into one end-of-2.7 schema #441 and didn't break CI there.
• Full PHPUnit suite: 143 tests / 607 assertions green
• PHPStan green; rule verified to fire on a smoke-test migration with addSql('SELECT 1') (then deleted)
• CI green on this PR

Out of scope (deferred)

• Native SQL in entity listeners — same conversion needs doing there too, but this PR is scoped to migrations because of the natural fit with WIP: consolidate 25 historical 2.x migrations into one end-of-2.7 schema #441.
• Adding Postgres / SQLite to the CI matrix to actually exercise the portability claim.
• Switching the deployment target away from MariaDB.

🤖 Generated with Claude Code