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.

entrypoint.sh

@@ -3,15 +3,20 @@
 # entrypoint.sh — TRM directus image boot flow
 #
 # Apply order (non-negotiable, per ROADMAP design rule #3):
-#   1. db-init runner — applies db-init/*.sql migrations against Postgres,
-#      guarded by the migrations_applied table. Owns DDL Directus does not
-#      manage (positions hypertable, faulty column).
+#   1. db-init runner (PRE-schema) — applies db-init/*.sql migrations against
+#      Postgres. These are migrations for tables Directus does NOT manage
+#      (positions hypertable, faulty column, future PostGIS extension).
 #   2. Directus schema apply — applies snapshots/schema.yaml so the running
-#      schema matches what's in git. No-op if schema.yaml doesn't exist
-#      (Phase 1 task 1.4/1.5 hasn't produced one yet).
-#   3. Directus bootstrap — idempotent first-boot setup (admin user, system
+#      schema matches what's in git. This creates the Directus-managed
+#      tables (organizations, events, entries, etc.). No-op if schema.yaml
+#      doesn't exist or is empty.
+#   3. db-init runner (POST-schema) — applies db-init-post/*.sql migrations.
+#      These are constraints/indexes on Directus-managed tables that the
+#      snapshot YAML format cannot capture (composite UNIQUE constraints).
+#      Must run AFTER schema-apply because the tables don't exist before then.
+#   4. Directus bootstrap — idempotent first-boot setup (admin user, system
 #      tables). Already-bootstrapped instances treat this as a fast no-op.
-#   4. Directus start under pm2-runtime — the upstream image's actual run
+#   5. Directus start under pm2-runtime — the upstream image's actual run
 #      pattern. pm2 provides crash recovery and signal handling inside the
 #      container.
 #
@@ -25,14 +30,17 @@ log() {
   printf '[entrypoint] %s\n' "$*"
 }
 
-log "step 1/4: db-init"
+log "step 1/5: db-init (pre-schema)"
 /directus/scripts/apply-db-init.sh
 
-log "step 2/4: directus schema apply"
+log "step 2/5: directus schema apply"
 /directus/scripts/schema-apply.sh
 
-log "step 3/4: directus bootstrap"
+log "step 3/5: db-init (post-schema)"
+DB_INIT_DIR=/directus/db-init-post /directus/scripts/apply-db-init.sh
+
+log "step 4/5: directus bootstrap"
 node /directus/cli.js bootstrap
 
-log "step 4/4: directus start (pm2-runtime)"
+log "step 5/5: directus start (pm2-runtime)"
 exec pm2-runtime start /directus/ecosystem.config.cjs