Split db-init into pre-schema and post-schema phases

CI dry-run revealed an architectural ordering bug: db-init/004 and
db-init/005 ALTER TABLE the Directus-managed tables (organization_users,
events, etc.), but db-init runs BEFORE schema-apply creates those
tables. On a fresh CI Postgres this fails with "relation does not
exist." Local dev never tripped this because we'd created the tables
via MCP first.

Fix: introduce a post-schema migration phase. Two db-init runs in the
entrypoint, with schema-apply in between:

  1. apply-db-init.sh   db-init/        → positions hypertable + faulty
                                          column (tables Directus does
                                          NOT manage)
  2. schema-apply.sh                    → creates Directus-managed tables
                                          from snapshots/schema.yaml
  3. apply-db-init.sh   db-init-post/   → composite UNIQUE constraints on
                                          the Directus-managed tables
  4. directus bootstrap
  5. directus start

Files moved:
  db-init/004_junction_unique_constraints.sql →
    db-init-post/001_junction_unique_constraints.sql
  db-init/005_event_participation_unique_constraints.sql →
    db-init-post/002_event_participation_unique_constraints.sql

Each ALTER TABLE in the post-schema migrations is now wrapped in a
pg_constraint existence guard for idempotency. This handles the dev DB
where the constraints already exist (from the original 004/005 runs +
the manual psql recovery during task 1.5's destructive-apply
incident). Old 004/005 rows in migrations_applied become orphans —
harmless.

Updates:
- Dockerfile: COPY db-init-post into the image
- entrypoint.sh: 4-step → 5-step flow with the post-schema run between
  schema-apply and bootstrap
- .gitea/workflows/build.yml: dry-run chains all three pre-boot scripts
  (pre-schema → schema-apply → post-schema); path filter includes
  db-init-post/**
- Task specs 1.4 and 1.5 Done sections: updated to reference the new
  db-init-post/ path (db-init/004 → db-init-post/001, etc.)

The reusable runner script (apply-db-init.sh) didn't need to change —
it already accepts DB_INIT_DIR and uses just the basename for the
guard-table key. The two phases share migrations_applied; filenames
don't collide because pre-schema and post-schema use distinct
descriptive names.

Phase 1 is still "done" — this is a Phase 1 architectural correction
exposed by the CI dry-run, not a new task.

.gitea/workflows/build.yml

@@ -6,6 +6,7 @@ on:
     paths:
       - 'snapshots/**'
       - 'db-init/**'
+      - 'db-init-post/**'
       - 'extensions/**'
       - 'scripts/**'
       - 'entrypoint.sh'
@@ -67,10 +68,12 @@ jobs:
       # -------------------------------------------------------------------------
       # Dry-run boot — the gate that protects the registry from broken images.
       #
-      # Runs only the two pre-boot scripts (apply-db-init.sh → schema-apply.sh)
-      # against the throwaway Postgres service above.  Intentionally does NOT run
-      # `directus bootstrap` or `directus start` — that would require waiting for
-      # the HTTP server to come up, which adds minutes and tests nothing new.
+      # Runs the pre-boot script chain (apply-db-init.sh → schema-apply.sh →
+      # apply-db-init.sh against db-init-post) against the throwaway Postgres
+      # service above.  Mirrors the entrypoint's first three steps.
+      # Intentionally does NOT run `directus bootstrap` or `directus start` —
+      # that would require waiting for the HTTP server to come up, which adds
+      # minutes and tests nothing new.
       #
       # --network host: the service container is mapped on 127.0.0.1:5432; the
       # docker run container sees it as localhost:5432 only when host networking
@@ -107,7 +110,7 @@ jobs:
             -e ADMIN_PASSWORD=ci-password-not-secret \
             -e PUBLIC_URL=http://localhost:8055 \
             trm-directus:ci \
-            -c '/directus/scripts/apply-db-init.sh && /directus/scripts/schema-apply.sh && echo "dry-run ok"'
+            -c '/directus/scripts/apply-db-init.sh && /directus/scripts/schema-apply.sh && DB_INIT_DIR=/directus/db-init-post /directus/scripts/apply-db-init.sh && echo "dry-run ok"'
 
       # -------------------------------------------------------------------------
       # Registry login — runs only if the dry-run succeeded (default: workflow