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.

Dockerfile

@@ -6,11 +6,14 @@
 # extensions) lands in Phase 5 when TypeScript extensions are introduced.
 #
 # Artifacts baked into the image at build time:
-#   /directus/snapshots/   — schema.yaml (generated; empty placeholder in Phase 1)
-#   /directus/db-init/     — numbered SQL migration files (Phase 1 task 1.3 fills these)
-#   /directus/scripts/     — shell helpers (Phase 1 tasks 1.2, 1.6 fill these)
-#   /directus/extensions/  — TypeScript extensions (Phase 5)
-#   /directus/entrypoint.sh — boot wrapper (real flow lands in Phase 1 task 1.7)
+#   /directus/snapshots/    — schema.yaml (generated)
+#   /directus/db-init/      — pre-schema migrations (positions hypertable etc.)
+#   /directus/db-init-post/ — post-schema migrations (constraints on Directus
+#                             managed tables; applied AFTER schema-apply)
+#   /directus/scripts/      — shell helpers (apply-db-init.sh, schema-apply.sh)
+#   /directus/extensions/   — TypeScript extensions (Phase 5)
+#   /directus/entrypoint.sh — boot wrapper (5-step flow: pre-schema db-init →
+#                             schema apply → post-schema db-init → bootstrap → start)
 #
 # No bind mounts of these directories in compose.dev.yaml — the image is the
 # source of truth. Reproducible across local, CI, and production environments.
@@ -34,10 +37,11 @@ RUN apk add --no-cache bash postgresql16-client
 # ---- Copy baked-in artifacts ----
 # Each COPY is conditional on the directory existing at build time.
 # .gitkeep files ensure the directories always exist so COPY never fails.
-COPY snapshots/  /directus/snapshots/
-COPY db-init/    /directus/db-init/
-COPY scripts/    /directus/scripts/
-COPY extensions/ /directus/extensions/
+COPY snapshots/    /directus/snapshots/
+COPY db-init/      /directus/db-init/
+COPY db-init-post/ /directus/db-init-post/
+COPY scripts/      /directus/scripts/
+COPY extensions/   /directus/extensions/
 COPY entrypoint.sh /directus/entrypoint.sh
 
 # Ensure the entrypoint is executable inside the image regardless of the host