docs: scope migration consolidation in UPGRADE.md and CHANGELOG

Documents the 2.x → 3.0 consolidation operator flow before the actual
squash lands: rewrites step 3 to use `doctrine:migrations:rollup`
instead of `migrate` for upgraders (orphaned versions would otherwise
cause migrate to fail), notes the 2.7.x prerequisite, and keeps the
fresh-install path on `migrate` against the single consolidated file.

CHANGELOG also flags the deferral of the `template` column drop
(icon, resources, description) from 3.0 to 3.1 so the consolidated
migration represents end-of-2.7 schema exactly — fresh and upgraded
installs stay symmetric for the eventual 3.1 drop.

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

Author: turegjorup

CHANGELOG.md

@@ -4,6 +4,13 @@ All notable changes to this project will be documented in this file.
 
 ## [Unreleased]
 
+- Consolidated 25 historical 2.x Doctrine migrations into a single schema-dump migration
+  representing the end-of-2.7 schema. Upgraders must be on the latest 2.7.x with every migration
+  applied, then run `doctrine:migrations:rollup` instead of `doctrine:migrations:migrate`. Fresh
+  installs are unaffected and continue to use `migrate`. See `UPGRADE.md` step 3.
+- Deferred the `template` column drop (icon, resources, description) from 3.0 to 3.1 so the
+  consolidated 3.0 migration represents end-of-2.7 schema exactly. The columns sit unused
+  through 3.0.x and 3.1 drops them uniformly across both fresh and upgraded installs.
 - Fixed Calendar and Colibo feed configuration urls and added [] result when no locationEndpoint is set.
 - Fixed baked-in `.env` shipping `APP_ENV=dev` in the API image; rewritten to `prod` at build time so
   direct reads don't try to bootstrap a dev environment the prod-only dependencies can't satisfy.

UPGRADE.md

@@ -73,12 +73,36 @@ Rename the following .env variables in `.env.local`:
 - From `APP_KEY_VAULT_SOURCE` to `KEY_VAULT_SOURCE`
 - From `APP_KEY_VAULT_JSON` to `KEY_VAULT_JSON`
 
-#### 3 - Run doctrine migrate
+#### 3 - Consolidate Doctrine migrations
+
+3.0 ships a single consolidated migration that represents the end-of-2.7 schema. The 25 historical
+2.x migrations have been removed from the repository.
+
+Because every upgrading database already matches that consolidated schema (via the 25 migrations it
+ran while on 2.x), there is nothing for `doctrine:migrations:migrate` to do — and running it would
+fail because of the orphaned version entries. Use `doctrine:migrations:rollup` instead, which
+truncates the `doctrine_migration_versions` table and inserts a single row marking the consolidated
+migration as already executed:
 
 ```shell
-docker compose exec phpfpm bin/console doctrine:migrations:migrate
+# Confirm the database is at the latest 2.7.x state before rolling up.
+# All 25 historical versions should appear as "migrated" / "available".
+docker compose exec phpfpm bin/console doctrine:migrations:status
+
+# Replace the 25 historical version entries with the single consolidated entry.
+# This does not run any SQL — it only rewrites the version-tracking table.
+docker compose exec phpfpm bin/console doctrine:migrations:rollup --no-interaction
 ```
 
+> **Prerequisite:** the database must be on the final 2.7.x release with every 2.x migration
+> applied. If `doctrine:migrations:status` (run while still on 2.7.x) reports any pending
+> migrations, run `doctrine:migrations:migrate` on 2.7.x first, then upgrade to 3.0 and continue
+> here.
+
+Fresh installs (no prior 2.x database) skip the rollup and run
+`doctrine:migrations:migrate` instead — it executes the single consolidated migration and brings
+the schema up in one step.
+
 #### 4 - Run template list command to see status for installed templates
 
 ```shell