ci: check the generated code; deploy: migrate before the switch

Two of Serverpod's own conventions, as its v4 project template and roles have them.

CI now runs `serverpod generate` (CLI pinned to the server's Serverpod version, like
the template's workflow) and fails if the committed generated code differs from its
output, so a model or endpoint changed without regenerating can't reach main. Checked in
a clean clone: today's code passes, a committed stale generated file fails.

redeploy.sh now applies the migrations in a run of their own, with Serverpod's
maintenance role (--role=maintenance --apply-migrations), after the dump and before
switching to the new server. That run exits with 0 only if the migrations worked, and
each migration is one transaction, so a failing one stops the deploy while the old
server keeps serving; before, the new server applied them at start and would have
crash-looped. Tested on the local stack: a deploy through the new step, and a failing
run (wrong database password) that exits with 1 after six attempts. AGENTS.md says
migrations must keep the old server working until the switch.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Tizian 「ティツィアーン」 <raisondetredev@pm.me>

deploy/compose.yaml

@@ -42,7 +42,8 @@ services:
     image: halkyon-learn-server
     restart: unless-stopped
     # Applies pending migrations at every start, then serves. One instance only, so
-    # no two servers ever migrate at once.
+    # no two servers ever migrate at once. (On learn.halkyon.eu, deploy/redeploy.sh has
+    # applied them in a run of their own before, so nothing is left to do here.)
     command: ["--apply-migrations"]
     environment:
       SERVERPOD_DATABASE_PASSWORD: ${POSTGRES_PASSWORD:?set POSTGRES_PASSWORD in deploy/.env}