Tasks 1.6 + 1.7 — schema tooling + real entrypoint flow

Two parallel tasks landing together. The boot pipeline is now wired
end-to-end: db-init → schema apply → directus bootstrap → pm2-runtime.
Live-verified by booting a fresh compose stack to a serving Directus
admin UI on :8055.

Task 1.6 — snapshot tooling:
- scripts/schema-snapshot.sh — host-side, dev-time. Verifies docker
  is on PATH and the directus compose service is running, runs
  `node /directus/cli.js schema snapshot --yes` inside the container,
  copies the YAML out to ./snapshots/schema.yaml. Used after admin-UI
  schema changes to capture the new state for git commit.
- scripts/schema-apply.sh — image-side, boot-time. Reads
  /directus/snapshots/schema.yaml, runs a dry-run preview, then
  applies. Gracefully skips when the snapshot is absent or whitespace-
  only (Phase 1 first-boot path before tasks 1.4/1.5 produce
  collections). SNAPSHOT_PATH env var override for CI flexibility.
- snapshots/README.md — lifecycle doc; warns against hand-editing.

Task 1.7 — real entrypoint flow:
- entrypoint.sh rewritten from Phase 1.1's placeholder to the
  4-step boot per ROADMAP design rule #3:
    1/4 db-init          → /directus/scripts/apply-db-init.sh
    2/4 schema apply     → /directus/scripts/schema-apply.sh
    3/4 directus bootstrap → node /directus/cli.js bootstrap
    4/4 directus start   → exec pm2-runtime start ecosystem.config.cjs
  set -euo pipefail halts boot on any step's non-zero exit. Each step
  emits a [entrypoint] log marker so an operator reading container
  logs sees which step failed.

Bug found and fixed during live verification:
- Both 1.6 scripts initially called bare `directus schema ...` as if
  the CLI were on PATH. Upstream directus/directus:11.17.4 does NOT
  expose `directus` on PATH — invocation is via `node /directus/cli.js`,
  same pattern as the entrypoint's bootstrap step. Both scripts
  corrected. Also added -T to docker compose exec in schema-snapshot.sh
  so the script works in non-TTY contexts (CI).

Phase 5 follow-up (non-blocking) flagged in 07's Done section: Directus
warns "Collection 'positions' doesn't have a primary key column and
will be ignored". The positions table uses UNIQUE INDEX (device_id, ts)
matching processor's pattern, not a PK constraint. Means positions is
not auto-registered as a Directus collection — fine for Phase 1, but
the operator faulty-flag workflow will need a custom endpoint or
manual collection registration in Phase 5.

ROADMAP marks 1.6 + 1.7 done. Phase 1 progress: 5/9 tasks complete
(1.1, 1.2, 1.3, 1.6, 1.7); 1.4, 1.5, 1.8, 1.9 remain.

entrypoint.sh

@@ -1,24 +1,38 @@
-#!/bin/sh
-# TRM directus — image entrypoint (placeholder).
+#!/usr/bin/env bash
+# =============================================================================
+# entrypoint.sh — TRM directus image boot flow
 #
-# Real flow (db-init runner → directus schema apply --yes → directus start)
-# lands in Phase 1 task 1.7.  Until then, this script replicates the upstream
-# Directus image CMD so the container boots normally during tasks 1.4 and 1.5
-# (admin UI schema work).
+# 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).
+#   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
+#      tables). Already-bootstrapped instances treat this as a fast no-op.
+#   4. Directus start under pm2-runtime — the upstream image's actual run
+#      pattern. pm2 provides crash recovery and signal handling inside the
+#      container.
 #
-# Upstream CMD (from directus/directus:11.17.4 Dockerfile):
-#   node cli.js bootstrap && pm2-runtime start ecosystem.config.cjs
-#
-# bootstrap: idempotent — initialises the DB schema on first run, reads
-#   ADMIN_EMAIL / ADMIN_PASSWORD to create the initial admin user.
-# pm2-runtime: starts the Directus process under PM2 so the container stays
-#   alive and restarts on crash without an outer supervisor.
-#
-# Exit codes are propagated: any non-zero exit causes the container to exit
-# with that code, which compose reports as an error.
+# Any failure halts boot (set -euo pipefail). Operators see a clear log line
+# in container output telling them which step failed.
+# =============================================================================
 
-set -e
+set -euo pipefail
 
+log() {
+  printf '[entrypoint] %s\n' "$*"
+}
+
+log "step 1/4: db-init"
+/directus/scripts/apply-db-init.sh
+
+log "step 2/4: directus schema apply"
+/directus/scripts/schema-apply.sh
+
+log "step 3/4: directus bootstrap"
 node /directus/cli.js bootstrap
 
+log "step 4/4: directus start (pm2-runtime)"
 exec pm2-runtime start /directus/ecosystem.config.cjs