feat: prep db identifiers for cross-platform (Postgres) portability

[turegjorup]

Note

Targets release/2.8.0. Lands here so the consolidated 3.0 migration in #441 / #442 can be regenerated against the portable entity shape and migrations:rollup stays honest for 2.x → 3.0 upgraders.

Why

Two things in the current schema are MariaDB-only and block fresh Postgres installs:

1. changed_idx index name reused on 15 tables. MariaDB scopes index names per-table; Postgres scopes them schema-wide, so the second CREATE INDEX changed_idx collides with relation "changed_idx" already exists.
2. user table is reserved in standard SQL and in Postgres. Doctrine doesn't auto-quote it, so generated DML like INSERT INTO user (...) is a syntax error on Postgres.

Without resolving these on 2.8, the consolidated 3.0 migration can't emit a Postgres-portable shape — it has to match what 2.x → 3.0 upgraders' MariaDB already has, or migrations:rollup lies. Fixing the divergence on 2.8 first means upgraders converge to the portable shape before they ever touch 3.0.

What

• Migration Version20260507120000 — RENAME INDEX changed_idx TO <table>_changed_idx on the 15 affected tables (feed, feed_source, media, playlist, playlist_screen_region, playlist_slide, screen, screen_campaign, screen_group, screen_group_campaign, screen_layout, screen_layout_regions, slide, template, theme). Reversible. No-op for MariaDB at runtime.
• Entity metadata — 15 #[ORM\Index(name: 'changed_idx')] updated to <table>_changed_idx; User entity gets #[ORM\Table(name: '\user`')]` so Doctrine emits the platform-native quoted identifier on every reference.
• CI gate — new validate-doctrine-schema-postgres job in pr.yaml spins up a Postgres 16 service container, applies entity metadata via doctrine:schema:update --force --complete, then runs doctrine:schema:validate. Catches future entity changes that break Postgres compatibility.

Why backtick-quote user instead of renaming it

A rename (user → app_user) was the first approach considered but it requires touching every table that FKs into user, plus realigning Doctrine's auto-derived hash-based index names (UNIQ_8D93D649… → UNIQ_88BDF3E9…). Backtick-quoting the identifier in the entity attribute is the standard Doctrine mechanism for reserved words: zero schema change, Doctrine emits `user` on MariaDB and "user" on Postgres from the same metadata. Trade-off accepted: any raw SQL outside Doctrine that hardcodes user would still need quoting on Postgres — but the only known instances (MultiTenantRepositoryTrait, RelationsChecksumCalculator) are deferred MariaDB-only paths called out in #442's "Out of scope" section anyway.

Test plan

• MariaDB: doctrine:migrations:migrate applies all 26 migrations cleanly; doctrine:schema:validate is in sync; full PHPUnit suite green (133 tests / 516 assertions, byte-identical to pristine release/2.7.0 baseline this PR was originally cut from).
• MariaDB: down/up cycle of the new migration verified.
• Postgres 16: doctrine:schema:update --force --complete applies entity metadata in 265 queries; doctrine:schema:validate is in sync; user table is created, no changed_idx collision.
• Retest against release/2.8.0 baseline after retarget.
• CI green on this PR (the new Postgres job is the proof point).

Follow-ups (not in this PR)

• After merge: regenerate Version20260506215847 in Consolidate 25 historical 2.x migrations into one end-of-2.8 schema #441 against the new entity shape so 3.0 fresh installs (on MariaDB or Postgres) emit the portable form. Rewrite migrations to Doctrine Schema tool + PHPStan enforcement #442's Schema-tool conversion stays intact — the regenerated DDL just uses the new index/identifier names.
• Native MariaDB SQL in MultiTenantRepositoryTrait and RelationsChecksumCalculator (deferred per Rewrite migrations to Doctrine Schema tool + PHPStan enforcement #442 description) still blocks Postgres at runtime; those need a separate conversion before Postgres becomes a real install target.

🤖 Generated with Claude Code