Task 1.4 — Org-level catalog collections

Seven collections + 3 directus_users custom fields, captured as
snapshots/schema.yaml (53 KB, 2,159 lines).

Collections:
- organizations          — UUID PK, name, slug UNIQUE
- vehicles               — UUID PK, make/model required, year/cc/vin/plate optional
- devices                — UUID PK, imei UNIQUE, model required
- organization_users     — junction with role enum (org-admin, race-director,
                            marshal, timekeeper, participant, viewer)
- organization_vehicles  — junction with registered_at
- organization_devices   — junction with registered_at
- directus_users         — extended with phone, birth_date, nationality

Six M2O relations on the junctions, all ON DELETE RESTRICT (matching
the schema-draft decision: deletion of an org/vehicle/device/user
requires explicit cleanup of dependents).

db-init/004_junction_unique_constraints.sql adds the composite UNIQUE
constraints on the three junctions:
  organization_users  (organization_id, user_id)
  organization_vehicles (organization_id, vehicle_id)
  organization_devices (organization_id, device_id)

Composite uniqueness lives in db-init rather than the Directus snapshot
because Directus's snapshot YAML format only captures single-column
unique constraints (the field-level is_unique flag). The migration file
documents the split inline.

Driven via the directus-local MCP server rather than admin-UI clicking
— programmatic create-collection/create-field/create-relation calls
against the running Directus instance, then `pnpm run schema:snapshot`
to capture the canonical YAML.

Live-verified: db-init/004 applies cleanly on container restart
(0 rows in the empty junctions, no constraint violations); schema-apply
against a snapshot-empty boot still skips correctly; all seven new
collections show up in the admin UI's data model navigation.

Snapshot includes positions and migrations_applied as auto-discovered
ghost entries (Directus introspects all public-schema tables). Harmless
— db-init creates them before schema-apply runs, so snapshot apply just
finds them already present.

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

db-init/004_junction_unique_constraints.sql

@@ -0,0 +1,60 @@
+-- 004_junction_unique_constraints.sql
+-- Composite UNIQUE constraints on the three org-junction tables.
+--
+-- Why this lives in db-init/ rather than being captured by Directus snapshot:
+--   Directus's field-level `is_unique` flag only generates single-column
+--   unique constraints. Junction tables need composite uniqueness on the
+--   pair (org, target) so the same user/vehicle/device cannot be registered
+--   twice within the same org. The snapshot YAML format does NOT capture
+--   composite unique constraints, so Directus cannot round-trip them.
+--   They belong here, in the same place the positions hypertable's DDL lives.
+--
+-- Owned by: task 1.4 (org catalog collections). The constraints are part of
+-- the data model contract, not a separate Phase 1 migration concern.
+--
+-- Idempotency: ALTER TABLE ... ADD CONSTRAINT is NOT idempotent. The
+-- migrations_applied guard table ensures this file runs at most once per
+-- environment. If a constraint already exists (e.g. ad-hoc on an existing
+-- stage DB), the operator must INSERT INTO migrations_applied (filename,
+-- checksum) VALUES ('004_junction_unique_constraints.sql', '<sha256>') to
+-- skip this file on next boot.
+
+ALTER TABLE organization_users
+  ADD CONSTRAINT organization_users_org_user_unique
+  UNIQUE (organization_id, user_id);
+
+ALTER TABLE organization_vehicles
+  ADD CONSTRAINT organization_vehicles_org_vehicle_unique
+  UNIQUE (organization_id, vehicle_id);
+
+ALTER TABLE organization_devices
+  ADD CONSTRAINT organization_devices_org_device_unique
+  UNIQUE (organization_id, device_id);
+
+-- -------------------------------------------------------------------------
+-- Assertion block: verify all three constraints landed.
+-- -------------------------------------------------------------------------
+DO $$ BEGIN
+
+  IF NOT EXISTS (
+    SELECT 1 FROM pg_constraint
+    WHERE conname = 'organization_users_org_user_unique'
+  ) THEN
+    RAISE EXCEPTION 'organization_users composite unique constraint missing';
+  END IF;
+
+  IF NOT EXISTS (
+    SELECT 1 FROM pg_constraint
+    WHERE conname = 'organization_vehicles_org_vehicle_unique'
+  ) THEN
+    RAISE EXCEPTION 'organization_vehicles composite unique constraint missing';
+  END IF;
+
+  IF NOT EXISTS (
+    SELECT 1 FROM pg_constraint
+    WHERE conname = 'organization_devices_org_device_unique'
+  ) THEN
+    RAISE EXCEPTION 'organization_devices composite unique constraint missing';
+  END IF;
+
+END $$;