chore(freight-api): upgrade api-common and iamapi-common packages

CLAUDE_NEW.md

@@ -154,13 +154,32 @@ no timeout and will wait forever.
 Migrations are the most dangerous surface in this repo. Two production-grade incidents have
 already come from it.
 
-- `migrationsRun: true` — **migrations run automatically on API boot**, with
-  `migrationsTransactionMode: 'each'`.
+- `migrationsRun: false` — **migrations do NOT run on API boot.** They run as a separate
+  one-shot step, via the Dockerfile's `migration` build target (`docker build --target
+  migration`), with `migrationsTransactionMode: 'each'`.
+  - CI: `.github/workflows/deploy.yml` builds the `migration` image and runs it
+    (`docker run --rm --env-file ...`) *before* building/deploying the app image.
+  - e2e: `docker-compose.e2e.yaml`'s `freight-migration-e2e` service runs once and
+    `freight-api-e2e` depends on it (`condition: service_completed_successfully`).
+  - Local dev (`docker-compose.yaml`) has no equivalent migration service yet — run
+    migrations yourself before `docker compose up freight-api`, e.g.
+    `docker build --target migration -f apps/edr-freight-api/Dockerfile -t freight-migration .`
+    then `docker run --rm --env-file apps/edr-freight-api/.env freight-migration`. Don't
+    use `pnpm run migrate` for this — it runs via `ts-node`, which never writes compiled
+    output to `dist/`, and the freight migrations glob only matches `dist/migrations/*.js`.
+    It silently applies zero freight migrations while exiting 0.
 - Consequences you must design for:
-  - Running several `nest start --watch` instances races `migrationsRun`. A non-idempotent
-    data migration can execute twice. Keep one instance.
   - A watch-mode hot reload does **not** re-run migrations. If you add a column that new
     code reads, apply it to the dev database yourself (idempotently) or fully restart.
+  - `apps/edr-freight-api/src/config/database.config.ts`'s `iamEntities` array is a
+    hand-maintained list of `@tria-plc/iamapi-common` entity classes. The live app never
+    notices when it's stale (`autoLoadEntities: true` papers over gaps via IAM's own
+    `forFeature()` registrations), but the standalone migration `DataSource`
+    (`data-source.ts`, no `autoLoadEntities`) does not have that fallback — a missing
+    entity throws `Entity metadata for X#y was not found` at `initialize()`, before a
+    single migration runs. **Every `@tria-plc/iamapi-common` version bump is a candidate
+    for this to break again** — diff the package's entity classes against `iamEntities`
+    when bumping it.
 - **Give every migration a unique timestamp.** 34 timestamps are currently shared by two or
   more migrations. TypeORM orders by timestamp and breaks ties non-deterministically. Before
   adding one, check the filename prefix is unused *and* higher than the newest recorded row.