feat: ignore deferred Template columns in schema:validate

Adds a postGenerateSchemaTable listener that injects icon, resources,
and description into the in-memory schema for the `template` table
before validate runs the entity-vs-DB diff. The columns are kept by
the consolidated 3.0 migration (so fresh installs and 2.x → 3.0
upgraders end up with the same schema), but the 3.0 Template entity
no longer maps them — without the listener, schema:validate would
exit non-zero and fail the doctrine.yaml PR workflow.

The listener is scoped to 3.0.x only. TODO[3.1] markers on both the
class and the service registration call out that this listener and
the deferred column-drop migration must land together in 3.1.

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

Author: turegjorup

config/services.yaml

@@ -191,6 +191,17 @@ services:
     App\EventListener\ThemeDoctrineEventListener:
         tags: [doctrine.orm.entity_listener]
 
+    # Suppresses `doctrine:schema:validate` complaints about three `template`
+    # columns the 3.0 `Template` entity no longer maps but the consolidated
+    # 3.0 migration still creates (icon, resources, description). See the
+    # listener class for the full rationale.
+    #
+    # TODO[3.1]: Remove this service registration together with the listener
+    # class itself when the deferred column-drop migration ships in 3.1.
+    App\EventListener\LegacyTemplateColumnsSchemaListener:
+        tags:
+            - { name: doctrine.event_listener, event: postGenerateSchemaTable }
+
     App\Service\MediaUploadTenantDirectoryNamer:
         public: true
 

src/EventListener/LegacyTemplateColumnsSchemaListener.php

@@ -0,0 +1,62 @@
+<?php
+
+declare(strict_types=1);
+
+namespace App\EventListener;
+
+use Doctrine\ORM\Tools\Event\GenerateSchemaTableEventArgs;
+
+/**
+ * Reconciles `doctrine:schema:validate` with the consolidated 3.0 migration.
+ *
+ * The 3.0 release squashes the historical 2.x migrations into a single
+ * schema-dump migration that recreates the end-of-2.7 schema verbatim — including
+ * three columns the 3.0 `Template` entity no longer maps:
+ *   - `template.icon`
+ *   - `template.resources`
+ *   - `template.description`
+ *
+ * Keeping those columns in the consolidated migration keeps fresh installs and
+ * 2.x → 3.0 upgraders symmetric (both end up with the columns), so the deferred
+ * drop migration can run uniformly in 3.1. The price is that, without help,
+ * `doctrine:schema:validate` reports the three columns as "extra in DB" and
+ * exits non-zero — which the `doctrine.yaml` PR workflow treats as a failure.
+ *
+ * This listener fires on `postGenerateSchemaTable` for the `template` table and
+ * adds the three legacy columns to the in-memory entity-side schema, so the
+ * comparison against the actual DB sees no mismatch and validate exits clean.
+ *
+ * The same effect bleeds into `doctrine:migrations:diff`: while this listener
+ * is registered, diff will not generate a "drop these columns" migration,
+ * because it believes the entity wants them.
+ *
+ * TODO[3.1]: Delete this class together with the deferred Template column-drop
+ * migration (originally `Version20250815092648`). Both must land in the same
+ * 3.1 change so `migrations:diff` is no longer suppressed when the columns are
+ * actually gone from the DB.
+ */
+final class LegacyTemplateColumnsSchemaListener
+{
+    public function postGenerateSchemaTable(GenerateSchemaTableEventArgs $args): void
+    {
+        $table = $args->getClassTable();
+
+        if ('template' !== $table->getName()) {
+            return;
+        }
+
+        $table->addColumn('icon', 'string', [
+            'length' => 255,
+            'notnull' => true,
+            'default' => '',
+        ]);
+        $table->addColumn('resources', 'json', [
+            'notnull' => true,
+        ]);
+        $table->addColumn('description', 'string', [
+            'length' => 255,
+            'notnull' => true,
+            'default' => '',
+        ]);
+    }
+}