feat(FN-190): move drizzle-kit to production dependencies (+8 more)

Commits merged:
- feat(FN-190): complete Step 9 — add Migration Workflow section to docs/INDEX.md
- fix(FN-190): apply biome import sorting and formatting
- feat(FN-190): complete Step 7 — write unit tests for migrate runner (5 tests)
- feat(FN-190): complete Step 6 — replace db:push with db:migrate in deploy workflow
- feat(FN-190): complete Step 5 — update Dockerfile with drizzle/ copy and start.sh CMD
- feat(FN-190): complete Step 4 — add db:migrate and db:migrate:dist scripts
- feat(FN-190): complete Step 3 — write migrate runner with bootstrap logic
- feat(FN-190): complete Step 2 — generate baseline Drizzle migration (46 tables)
- feat(FN-190): complete Step 1 — move drizzle-kit to production dependencies

Files changed:
.github/workflows/deploy.yml                    |    2 +-
 Dockerfile                                      |    6 +-
 apps/api/drizzle/0000_brief_guardian.sql        |  658 +++
 apps/api/drizzle/meta/0000_snapshot.json        | 5167 +++++++++++++++++++++++
 apps/api/drizzle/meta/_journal.json             |   13 +
 apps/api/package.json                           |    4 +-
 apps/api/src/database/__tests__/migrate.spec.ts |  179 +
 apps/api/src/database/migrate.ts                |  160 +
 apps/api/start.sh                               |    8 +
 docs/INDEX.md                                   |   24 +-
 pnpm-lock.yaml                                  |    6 +-
 11 files changed, 6220 insertions(+), 7 deletions(-)

Fusion-Task-Id: FN-190

docs/INDEX.md

@@ -354,6 +354,28 @@ catalogVehicles
 - `emex_*` — EMEX scraper cache (similar structure with translations)
 - `parts_catalogs_*` — PartsCatalogs API cache (defined in `parts-catalogs.ts`)
 
+### Migration Workflow
+
+**Strategy:** Formal Drizzle SQL migrations with automated startup.
+
+**Schema change workflow:**
+1. Edit schema files in `apps/api/src/database/schema/`
+2. Run `pnpm db:generate` — produces a timestamped `.sql` file in `apps/api/drizzle/`
+3. Review the SQL diff in PR (the migration is version-controlled alongside code)
+4. Commit and deploy — migration runs automatically on container startup
+
+**Container startup:** The API server runs `apps/api/start.sh` which executes `node dist/database/migrate.js` BEFORE starting the NestJS server. This ensures all pending migrations are applied before any code runs.
+
+**Bootstrap note:** Existing databases with no migration history (`__drizzle_migrations` table missing) are automatically bootstrapped on first run. The bootstrap creates the tracking table and marks all baseline migrations as already applied (no SQL is executed against the live DB). This is safe for databases previously managed via `pnpm db:push`.
+
+**Manual commands:**
+- `pnpm db:migrate` — Run migrations in dev (uses `tsx` for direct TS execution)
+- `pnpm db:migrate:dist` — Run migrations against compiled JS (for production manual override)
+- `pnpm db:generate` — Create a new migration from schema changes
+- `pnpm db:push` — Direct schema push (still available for local dev, discouraged for shared environments)
+
+**Worker process:** The BullMQ worker overrides the Docker CMD in `docker-compose.coolify.yml` and does NOT run migrations. Only the API service handles migrations, preventing race conditions.
+
 ### Job Queues
 
 **Framework:** BullMQ with Redis
@@ -752,7 +774,7 @@ Dependencies: Radix UI (accordion, dialog, dropdown-menu, label, popover, select
 2. `git pull origin main`
 3. `pnpm install`
 4. `pnpm build`
-5. `pnpm db:push` (migrations)
+5. `pnpm db:migrate` (migrations)
 6. PM2 reload all
 
 ### PM2 Configuration